| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Changing types of block and chunk sizes in memory contexts |
| Date: | 2023-06-29 03:46:47 |
| Message-ID: | CAApHDvpMSrMu6-C3h+Q5APU7Wv-SJFS5J4LaDjmHEXYBrbN5_g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 29 Jun 2023 at 09:26, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> AllocSetContext 224B -> 208B (4 cachelines)
> GenerationContext 152B -> 136B (3 cachelines)
> SlabContext 200B -> 200B (no change, adds 4B hole)
>
> Nothing else changes, AFAICS.
I don't think a lack of a reduction in the number of cache lines is
the important part. Allowing more space on the keeper block, which is
at the end of the context struct seems more useful. I understand that
the proposal is just to shave off 12 bytes and that's not exactly huge
when it's just once per context, but we do create quite a large number
of contexts with ALLOCSET_SMALL_SIZES which have a 1KB initial block
size. 12 bytes in 1024 is not terrible.
It's not exactly an invasive change. It does not add any complexity
to the code and as far as I can see, about zero risk of it slowing
anything down.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2023-06-29 04:05:34 | Re: pg_decode_message vs skip_empty_xacts and xact_wrote_changes |
| Previous Message | Richard Guo | 2023-06-29 03:25:53 | Re: Another incorrect comment for pg_stat_statements |