| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Subject: | Re: ModifyTable overheads in generic plans |
| Date: | 2021-04-07 00:00:25 |
| Message-ID: | 20210407000025.bqqdzfwp5bbaxfm4@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-04-06 19:24:11 -0400, Tom Lane wrote:
> I also could not get excited about postponing initialization of RETURNING
> or WITH CHECK OPTIONS expressions. I grant that that can be helpful
> when those features are used, but I doubt that RETURNING is used that
> heavily, and WITH CHECK OPTIONS is surely next door to nonexistent
> in performance-critical queries.
FWIW, there's a number of ORMs etc that use it on every insert (there's
not really a better way to get the serial when you also want to do
pipelining).
> nparts TPS
> 0 12152
> 10 8672
> 100 2753
> 1000 314
>
> and after the two patches I just pushed, it looks like:
>
> 0 12105
> 10 9928
> 100 5433
> 1000 938
>
> So while there's certainly work left to do, that's not bad for
> some low-hanging-fruit grabbing.
Nice. 3x at the upper end is pretty good.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2021-04-07 00:25:40 | Re: [HACKERS] logical decoding of two-phase transactions |
| Previous Message | Andres Freund | 2021-04-06 23:58:37 | Re: Autovacuum on partitioned table (autoanalyze) |