Re: Tid scan improvements - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Tid scan improvements
Date
Msg-id 0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com
Whole thread Raw
In response to Re: Tid scan improvements  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Tid scan improvements
List pgsql-hackers
On 11/22/18 8:41 AM, David Rowley wrote:
 >
> ...
> 
> 3. I'd rather see EnsureTidRangeSpace() keep doubling the size of the
> allocation until it reaches the required size. See how
> MakeSharedInvalidMessagesArray() does it.  Doing it this way ensures
> we always have a power of two sized array which is much nicer if we
> ever reach the palloc() limit as if the array is sized at the palloc()
> limit / 2 + 1, then if we try to double it'll fail.  Of course, it's
> unlikely to be a problem here, but... the question would be how to
> decide on the initial size.
> 

I think it kinda tries to do that in some cases, by doing this:

     *numAllocRanges *= 2;

     ...

     tidRanges = (TidRange *)
         repalloc(tidRanges,
                  *numAllocRanges * sizeof(TidRange));

The problem here is that what matters is not numAllocRanges being 2^N, 
but the number of bytes allocated being 2^N. Because that's what ends up 
in AllocSet, which keeps lists of 2^N chunks.

And as TidRange is 12B, so this is guaranteed to waste memory, because 
no matter what the first factor is, the result will never be 2^N.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Online verification of checksums
Next
From: Tomas Vondra
Date:
Subject: Re: 64-bit hash function for hstore and citext data type