From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "kato-sho(at)fujitsu(dot)com" <kato-sho(at)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performing partition pruning using row value |
Date: | 2020-07-10 01:00:17 |
Message-ID: | CA+HiwqGUGKwfdTNGbAitdEYCBs-fgPH1BJ88Hn51a-oegeML9A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 10, 2020 at 9:35 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Thu, Jul 9, 2020 at 7:57 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-07-10 01:06:06 | Re: A patch for get origin from commit_ts. |
Previous Message | Etsuro Fujita | 2020-07-10 00:35:53 | Re: Performing partition pruning using row value |