| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: deep copy with mutation? |
| Date: | 2026-06-02 23:10:22 |
| Message-ID: | CAApHDvqjy_4xLusOWBx99jt+khJ4ev5sEEdS5aKokXjVpzkHSQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 30 Apr 2026 at 09:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I'm not entirely certain how much this kind of thing matters -- maybe
> it's better to have the copy routine be as simple as possible and
> accept the cost of walking the whole tree immediately afterwards to
> make changes? Perhaps this kind of thing is so cache-friendly that the
> mutation pass is really cheap? But it certainly kinda *looks*
> inefficient...
These tree traversals are often pretty expensive in terms of the
overhead of stack manipulation and function call overhead. Having
something to reduce those, I expect, could be made to demonstrate
speedups. We also shouldn't forget about the reduction in pallocs and
wasted memory from the to-be-mutated-later nodes having a redundant
copy made by copyObject(). There's also the memory fragmentation issue
of that, which would increase the likelihood of cache misses later due
to non-consecutive memory access in later traversals. Whereas if the
copy/mutate was done in one pass, and palloc() didn't reuse any chunks
from the freelists, then the memory would be consecutive in tree
traversal order.
I think the main deciding factor whether we should do this is the
complexity of doing it in terms of code changes vs. observed speedup.
In the first example you gave, map_partition_varattnos() is called
twice, so if that were to perform a full copy during that traversal,
then you'd need to make that function do both replacements at the same
time to avoid copying again on the next call.
Maybe you could quickly figure out if this is worth the trouble by
adding some additional copyObjects in the places you think could be
made better to see if you can see a slowdown. If you can't measure
that, then you could probably assume that removing a traversal
wouldn't result in much of a speedup.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-06-02 23:29:05 | Re: Unify parallel worker handling for index builds and instrumentation |
| Previous Message | David Rowley | 2026-06-02 22:32:43 | Re: Wrong unsafe-flag test in check_output_expressions() |