| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-12-01 11:21:06 |
| Message-ID: | 20221201112106.gjlcv6nvndjbnoez@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022-Dec-01, Amit Langote wrote:
> Hmm, how about keeping the [Merge]Append's parent relation's RT index
> in the PartitionPruneInfo and passing it down to
> ExecInitPartitionPruning() from ExecInit[Merge]Append() for
> cross-checking? Both Append and MergeAppend already have a
> 'apprelids' field that we can save a copy of in the
> PartitionPruneInfo. Tried that in the attached delta patch.
Ah yeah, that sounds about what I was thinking. I've merged that in and
pushed to github, which had a strange pg_upgrade failure on Windows
mentioning log files that were not captured by the CI tooling. So I
pushed another one trying to grab those files, in case it wasn't an
one-off failure. It's running now:
https://cirrus-ci.com/task/5857239638999040
If all goes well with this run, I'll get this 0001 pushed.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Shinderuk | 2022-12-01 11:21:47 | Re: Bug in row_number() optimization |
| Previous Message | Alvaro Herrera | 2022-12-01 11:16:39 | Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas |