On Fri, Aug 4, 2017 at 2:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila <amit.kapila16@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