From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reduce TupleHashEntryData struct size by half |
Date: | 2025-01-14 09:01:57 |
Message-ID: | CAApHDvoCa=_eAhKkLZ=VXEG-N1JU_P0ykL1iR6iS+tEbYQt2qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 14 Jan 2025 at 11:11, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Sun, 2025-01-12 at 14:54 +1300, David Rowley wrote:
> > I wonder if there's some other better way of doing this. Would it be
> > worth having some function like ExecCopySlotMinimalTuple() that
> > accepts an additional parameter so that the palloc allocates N more
> > bytes at the end? Maybe it's worth hunting around to see if there's
> > any other executor nodes that could benefit from that infrastructure.
>
> That would be convenient, but doesn't seem like a great separation of
> responsibilities. Perhaps some API that separated the length
> calculation, and accepted a caller-supplied buffer?
The trick would be to ensure ExecClearTuple() still works. You
obviously don't want to try and pfree() something that isn't a pointer
to a palloc'd chunk. I'm not sure what the best API is, but I do see
there are other places that might benefit from something that allows
this. The two usages of ExecCopySlotMinimalTuple() in nodeMemoize.c
are candidates.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Luca Ferrari | 2025-01-14 09:08:05 | question about executor hooks |
Previous Message | John Naylor | 2025-01-14 08:58:40 | Re: Sort functions with specialized comparators |