From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, andrewbille(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Date: | 2025-10-16 01:36:23 |
Message-ID: | CAApHDvrNozFw_K2cbe5oLmxt0VSbU5yweKxvybAvnHt+K_MAaA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 16 Oct 2025 at 14:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > Just to put that to the test, I tried the attached.
>
> I'm confused by all the extraneous changes in this?
It includes the query rewrite too in order to get rid of the
subqueries in the targetlist to pg_attribute. There are 3 of those in
total. When ignore_system_indexes is on, that means a 3x Seq Scans to
pg_attribute per returned row. The rewrite gets rid of that and turns
that into a single join to pg_attribute which allows the planner to
hash or merge join to it. We could just do the conditional calling of
the pg_get_*def() functions, but performance would still be terrible
for ignore_system_indexes=on due to the Seq Scans, and slightly worse
overall.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-16 01:47:52 | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |
Previous Message | Tom Lane | 2025-10-16 01:31:29 | Re: BUG #19086: pg_dump --data-only selects and do not uses index definitions for the dumped tables. |