Re: making update/delete of inheritance trees scale better
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-31T06:14:06Z
Lists: pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes: > On Wed, Mar 31, 2021 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> ... I've complained before that apply_scanjoin_target_to_paths >> is brute-force and needs to be rewritten, but I don't really want to >> undertake that task right now. > I remember having *unsuccessfully* tried to make > apply_scanjoin_target_to_paths() do the targetlist pushdown for the > traditional inheritance cases as well. I agree that rethinking the > whole apply_scanjoin_target_to_paths() approach might be a better use > of our time. It has a looping-over-the-whole-partition-array > bottleneck for simple lookup queries that I have long wanted to > propose doing something about. I was wondering if we could get anywhere by pushing more smarts down to the level of create_projection_path itself, ie if we see we're trying to apply a projection to an AppendPath then push it underneath that automatically. Then maybe some of the hackery in apply_scanjoin_target_to_paths could go away. There's already an attempt at that in apply_projection_to_path, but it's not completely clean so there are callers that can't use it. Maybe a little more thought about how to do that in a way that violates no invariants would yield dividends. regards, tom lane
Commits
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited