JSONB Array of Strings (with GIN index) versus Split Rows (B-Tree Index)












0















I have a database which stores receiver to indicate which account the data relates to. This has led to tons of duplication of data, as one set of data may create 3 separate rows, where the only difference is the receiver column.



|---------------------|------------------|---------------------|------------------|
| Receiver | Event | Date | Location |
|---------------------|------------------|---------------------|------------------|
| Alpha | 3 | 12 | USA |
|---------------------|------------------|---------------------|------------------|
| Bravo | 3 | 12 | USA |
|---------------------|------------------|---------------------|------------------|
| Charlie | 3 | 12 | USA |
|---------------------|------------------|---------------------|------------------|


While redesigning the database, I have considered using an array with a GIN index instead of the current B-Tree index on receiver. My proposed new table would look like this:



|-------------------------------|--------------|------------|-------------------|
| Receivers | Event | Date | Location |
|-------------------------------|--------------|------------|-------------------|
| ["Alpha", "Bravo", "Charlie"] | 3 | 12 | USA |
|-------------------------------|--------------|------------|-------------------|


More Information:




  • Receiver names are of the type (a-z, 1-5, .)

  • 95% of all queries currently look like this: SELECT * FROM table WHERE Receiver = Alpha, with the new format this would be SELECT * FROM table WHERE receivers @> '"Alpha"'::jsonb;

  • The table currently contains over 4 billion rows (with duplication) and the new proposed schema would cut it down to under 2 billion rows.


Question:




  1. Does it make more sense to use Postgres Native Text Array?

  2. Would a jsonb_path_ops GIN index on receivers make sense here?

  3. Which option is more efficient? Which is faster?










share|improve this question









New contributor




Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

























    0















    I have a database which stores receiver to indicate which account the data relates to. This has led to tons of duplication of data, as one set of data may create 3 separate rows, where the only difference is the receiver column.



    |---------------------|------------------|---------------------|------------------|
    | Receiver | Event | Date | Location |
    |---------------------|------------------|---------------------|------------------|
    | Alpha | 3 | 12 | USA |
    |---------------------|------------------|---------------------|------------------|
    | Bravo | 3 | 12 | USA |
    |---------------------|------------------|---------------------|------------------|
    | Charlie | 3 | 12 | USA |
    |---------------------|------------------|---------------------|------------------|


    While redesigning the database, I have considered using an array with a GIN index instead of the current B-Tree index on receiver. My proposed new table would look like this:



    |-------------------------------|--------------|------------|-------------------|
    | Receivers | Event | Date | Location |
    |-------------------------------|--------------|------------|-------------------|
    | ["Alpha", "Bravo", "Charlie"] | 3 | 12 | USA |
    |-------------------------------|--------------|------------|-------------------|


    More Information:




    • Receiver names are of the type (a-z, 1-5, .)

    • 95% of all queries currently look like this: SELECT * FROM table WHERE Receiver = Alpha, with the new format this would be SELECT * FROM table WHERE receivers @> '"Alpha"'::jsonb;

    • The table currently contains over 4 billion rows (with duplication) and the new proposed schema would cut it down to under 2 billion rows.


    Question:




    1. Does it make more sense to use Postgres Native Text Array?

    2. Would a jsonb_path_ops GIN index on receivers make sense here?

    3. Which option is more efficient? Which is faster?










    share|improve this question









    New contributor




    Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      0












      0








      0








      I have a database which stores receiver to indicate which account the data relates to. This has led to tons of duplication of data, as one set of data may create 3 separate rows, where the only difference is the receiver column.



      |---------------------|------------------|---------------------|------------------|
      | Receiver | Event | Date | Location |
      |---------------------|------------------|---------------------|------------------|
      | Alpha | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|
      | Bravo | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|
      | Charlie | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|


      While redesigning the database, I have considered using an array with a GIN index instead of the current B-Tree index on receiver. My proposed new table would look like this:



      |-------------------------------|--------------|------------|-------------------|
      | Receivers | Event | Date | Location |
      |-------------------------------|--------------|------------|-------------------|
      | ["Alpha", "Bravo", "Charlie"] | 3 | 12 | USA |
      |-------------------------------|--------------|------------|-------------------|


      More Information:




      • Receiver names are of the type (a-z, 1-5, .)

      • 95% of all queries currently look like this: SELECT * FROM table WHERE Receiver = Alpha, with the new format this would be SELECT * FROM table WHERE receivers @> '"Alpha"'::jsonb;

      • The table currently contains over 4 billion rows (with duplication) and the new proposed schema would cut it down to under 2 billion rows.


      Question:




      1. Does it make more sense to use Postgres Native Text Array?

      2. Would a jsonb_path_ops GIN index on receivers make sense here?

      3. Which option is more efficient? Which is faster?










      share|improve this question









      New contributor




      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      I have a database which stores receiver to indicate which account the data relates to. This has led to tons of duplication of data, as one set of data may create 3 separate rows, where the only difference is the receiver column.



      |---------------------|------------------|---------------------|------------------|
      | Receiver | Event | Date | Location |
      |---------------------|------------------|---------------------|------------------|
      | Alpha | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|
      | Bravo | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|
      | Charlie | 3 | 12 | USA |
      |---------------------|------------------|---------------------|------------------|


      While redesigning the database, I have considered using an array with a GIN index instead of the current B-Tree index on receiver. My proposed new table would look like this:



      |-------------------------------|--------------|------------|-------------------|
      | Receivers | Event | Date | Location |
      |-------------------------------|--------------|------------|-------------------|
      | ["Alpha", "Bravo", "Charlie"] | 3 | 12 | USA |
      |-------------------------------|--------------|------------|-------------------|


      More Information:




      • Receiver names are of the type (a-z, 1-5, .)

      • 95% of all queries currently look like this: SELECT * FROM table WHERE Receiver = Alpha, with the new format this would be SELECT * FROM table WHERE receivers @> '"Alpha"'::jsonb;

      • The table currently contains over 4 billion rows (with duplication) and the new proposed schema would cut it down to under 2 billion rows.


      Question:




      1. Does it make more sense to use Postgres Native Text Array?

      2. Would a jsonb_path_ops GIN index on receivers make sense here?

      3. Which option is more efficient? Which is faster?







      postgresql database-design index postgresql-performance postgresql-11






      share|improve this question









      New contributor




      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 5 mins ago







      Syed Jafri













      New contributor




      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 1 hour ago









      Syed JafriSyed Jafri

      11




      11




      New contributor




      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Syed Jafri is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          0






          active

          oldest

          votes











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "182"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });






          Syed Jafri is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f228768%2fjsonb-array-of-strings-with-gin-index-versus-split-rows-b-tree-index%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          0






          active

          oldest

          votes








          0






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          Syed Jafri is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          Syed Jafri is a new contributor. Be nice, and check out our Code of Conduct.













          Syed Jafri is a new contributor. Be nice, and check out our Code of Conduct.












          Syed Jafri is a new contributor. Be nice, and check out our Code of Conduct.
















          Thanks for contributing an answer to Database Administrators Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f228768%2fjsonb-array-of-strings-with-gin-index-versus-split-rows-b-tree-index%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          SQL Server 17 - Attemping to backup to remote NAS but Access is denied

          Always On Availability groups resolving state after failover - Remote harden of transaction...

          Restoring from pg_dump with foreign key constraints