| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: generic plans and "initial" pruning |
| Date: | 2022-07-27 16:27:06 |
| Message-ID: | CA+TgmoZzmThMvz9HVqSTD1ESWbzn=KpWpag6SMsJQi+NbN3ghQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 26, 2022 at 11:01 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> Needed to be rebased again, over 2d04277121f this time.
0001 adds es_part_prune_result but does not use it, so maybe the
introduction of that field should be deferred until it's needed for
something.
I wonder whether it's really necessary to added the PartitionPruneInfo
objects to a list in PlannerInfo first and then roll them up into
PlannerGlobal later. I know we do that for range table entries, but
I've never quite understood why we do it that way instead of creating
a flat range table in PlannerGlobal from the start. And so by
extension I wonder whether this table couldn't be flat from the start
also.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2022-07-27 16:37:16 | Re: making relfilenodes 56 bits |
| Previous Message | Dilip Kumar | 2022-07-27 16:19:38 | Re: making relfilenodes 56 bits |