| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Subject: | Re: ModifyTable overheads in generic plans |
| Date: | 2021-04-08 04:54:39 |
| Message-ID: | CAApHDvqADVMKbKQE8peDy1+c4tFtAE=nCFous5wMZA4g=ESQVg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 8 Apr 2021 at 15:32, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> There's 10-20% improvement in this case too for various partition
> counts, which really has more to do with 86dc90056 than the work done
> here.
I'm not sure of the exact query you're running, but I imagine the
reason that it wasn't that slow with custom plans was down to
428b260f87.
So the remaining slowness for the generic plan case with large numbers
of partitions in the plan vs custom plans plan-time pruning is a)
locking run-time pruned partitions; and; b) permission checks during
executor startup?
Aside from the WCO and RETURNING stuff you mentioned, I mean.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-04-08 05:16:02 | Re: SQL-standard function body |
| Previous Message | Kohei KaiGai | 2021-04-08 04:43:25 | Re: TRUNCATE on foreign table |