Re: making update/delete of inheritance trees scale better
От | Tom Lane |
---|---|
Тема | Re: making update/delete of inheritance trees scale better |
Дата | |
Msg-id | 3126956.1617171246@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: making update/delete of inheritance trees scale better (Amit Langote <amitlangote09@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: