Re: Performing partition pruning using row value
От | Amit Langote |
---|---|
Тема | Re: Performing partition pruning using row value |
Дата | |
Msg-id | CA+HiwqGUGKwfdTNGbAitdEYCBs-fgPH1BJ88Hn51a-oegeML9A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performing partition pruning using row value (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
RE: Performing partition pruning using row value
|
Список | pgsql-hackers |
On Fri, Jul 10, 2020 at 9:35 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Thu, Jul 9, 2020 at 7:57 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > > On 2020/07/09 19:45, Etsuro Fujita wrote: > > > Please add the patch to the next CF so that it does not get lost. > > > > Is this a bug rather than new feature? > > I think it's a limitation rather than a bug that partition pruning > doesn't support row-wise comparison, so I think the patch is a new > feature. I tend to think so too. IMO, partition pruning, like any other optimization, works on a best-effort basis. If the result it produces is wrong, now that would be a bug, but I don't think that's the case here. However, I do think it was a bit unfortunate that we failed to consider RowCompare expressions when developing partition pruning given, that index scans are already able to match them. Speaking of which, I hope that Kato-san has looked at functions match_rowcompare_to_indexcol(), expand_indexqual_rowcompare(), etc. in indxpath.c as starting points for the code to match RowCompares to partition keys. -- Amit Langote EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: