Re: Tid scan improvements

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Edmund Horner <ejrh00(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Tid scan improvements
Date: 2018-11-22 18:03:21
Message-ID: 0aad6687-037c-5f2f-4bbe-50f68e5c4cf6@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-11-22 18:51:25 Re: 64-bit hash function for hstore and citext data type
Previous Message Stephen Frost 2018-11-22 17:39:28 Re: Online verification of checksums