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
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 |