From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru> |
Subject: | Re: GiST VACUUM |
Date: | 2018-08-05 11:18:59 |
Message-ID: | 43f15ab5-dd95-97d4-658b-e9954ca986a6@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31/07/18 23:06, Andrey Borodin wrote:
>> On a typical GiST index, what's the ratio of leaf vs. internal
>> pages? Perhaps an array would indeed be better.
>
> Typical GiST has around 200 tuples per internal page. I've switched
> to List since it's more efficient than bitmap.
Hmm. A ListCell is 16 bytes, plus the AllocChunk header, 16 bytes. 32
bytes per internal page in total, while a bitmap consumes one bit per
page, leaf or internal. If I'm doing
my math right, assuming the ratio of leaf pages vs internal pages is
1:200, a List actually consumes more memory than a bitmap; 256 bits per
internal page, vs. 200 bits. An array, with 4 bytes per block number,
would be the winner here.
> But I have to note that default growth strategy of Bitmap is not
> good: we will be repallocing byte by byte.
True, that repallocing seems bad. You could force it to be pre-allocated
by setting the last bit. Or add a function to explicitly enlarge the bitmap.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-08-05 12:04:30 | Re: Explain buffers wrong counter with parallel plans |
Previous Message | Heikki Linnakangas | 2018-08-05 11:00:04 | Re: Negotiating the SCRAM channel binding type |