| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Should we add GUCs to allow partition pruning to be disabled? |
| Date: | 2018-05-10 16:50:25 |
| Message-ID: | CAKFQuwbGZ-jAO=WJ8skOahJB0OARYN0EAVTEAGzuqoh2=De6eg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 10, 2018 at 8:57 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
> b) by default, no partitions are
> scanned, and we examine the query to determine which ones must be
> scanned.
>
There is an element of logic that says "by default, no partitions are
scanned" is not a reasonable behavior mode. Thus an alternative analogy
would be:
Bucket A is the set of all relevant partitions in the tree
Pruning: remove from bucket A those which we know we can skip; then iterate
over A
Selection: choose those items from A that are possible holders of our data
and process each one (place all selected items into bucket B and iterate
over B if you want to perform selection in total first).
As a user I don't really need to know which model is implemented and the
name doesn't necessarily imply the implementation. Pruning seems to be the
commonly-used term for this feature and we should stick with that.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-05-10 16:58:49 | Re: Should we add GUCs to allow partition pruning to be disabled? |
| Previous Message | Tom Lane | 2018-05-10 16:18:19 | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |