On Fri, Aug 4, 2017 at 2:49 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> I have increased the number of hash bitmap pages as a separate patch. >>> I am not completely sure if it is a good idea to directly increase it >>> to 1024 as that will increase the size of hashmetapagedata from 960 >>> bytes to 4544 bytes. Shall we increase it to 512? >> >> I don't quite see what the problem is with increasing it to 4544 >> bytes. What's your concern? > > Nothing as such. It is just that the previous code might have some > reason to keep it at 128, probably if there are that many overflow > bucket pages, then it is better to reindex the index otherwise the > performance might suck while traversing the long overflow chains. In > general, I see your point that if we can provide user to have that big > overflow space, then let's do it.
Yeah. The only concern I see is that one doesn't want to run out of space in the metapage when future patches come along and try to do new things. But 4544 bytes still leaves quite a bit of headroom, and I think it's better to solve a problem we know we have right now than try to save too much space for future needs that may or may not occur. Maybe at some point this whole thing needs a broader rethink, but the fact that somebody hit the current limit before we got out of beta makes me think that we should be fairly aggressive in trying to ameliorate the problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers