| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PG15 beta1 sort performance regression due to Generation context change |
| Date: | 2022-05-23 21:56:46 |
| Message-ID: | CAApHDvoEC1=9kp8_f6B9rMySnxwjftJzQLWb_ss-=vj+Q6dZ3g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 24 May 2022 at 09:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> However, here's a different idea: how badly do we need the "size"
> field in GenerationChunk? We're not going to ever recycle the
> chunk, IIUC, so it doesn't matter exactly how big it is. When
> doing MEMORY_CONTEXT_CHECKING we'll still want requested_size,
> but that's not relevant to performance-critical cases.
Interesting idea. However, I do see a couple of usages of the "size"
field away from MEMORY_CONTEXT_CHECKING builds:
GenerationRealloc: uses "size" to figure out if the new size is
smaller than the old size. Maybe we could just always move to a new
chunk regardless of if the new size is smaller or larger than the old
size.
GenerationGetChunkSpace: Uses "size" to figure out the amount of
memory is used by the chunk. I'm not sure how we'd work around the
fact that USEMEM() uses that extensively in tuplesort.c to figure out
how much memory we're using.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2022-05-23 22:02:00 | Re: PG15 beta1 sort performance regression due to Generation context change |
| Previous Message | Robert Haas | 2022-05-23 21:51:53 | Re: allow building trusted languages without the untrusted versions |