From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <hornschnorter(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: "SELECT ... FROM DUAL" is not quite as silly as it appears |
Date: | 2019-01-15 00:11:08 |
Message-ID: | CAKJS1f9RAWOscHa0Tboo4XhgaMqq_hHhXdapsxGV-Yru4mzr-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 15 Jan 2019 at 09:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > SELECT 1; I believe is a common query for some connection poolers as a
> > sort of ping to the database. In light of that, the performance drop
> > of 2 microseconds per query is not going to amount to very much in
> > total for that use case. i.e you'll need to do half a million pings
> > before it'll cost you 1 second of additional CPU time.
>
> Yeah, I agree this is not something to get hot & bothered over, but
> I thought it was worth spending an hour seeing if there were any
> easy wins. Not much luck.
Thanks for putting in the effort.
> Anyway, herewith v6, rebased up to HEAD, with the build_simple_rel
> improvement and the regression test fix I mentioned earlier.
I had a look at these changes, I only have 1 comment:
1. I don't think having a table named "dual" makes a whole lot of
sense for a table with a single row. I'm sure we can come up with a
more suitably named table to serve the purpose. How about "single"?
INSERT INTO J2_TBL VALUES (0, NULL);
INSERT INTO J2_TBL VALUES (NULL, NULL);
INSERT INTO J2_TBL VALUES (NULL, 0);
+-- useful in some tests below
+create temp table dual();
+insert into dual default values;
+analyze dual;
(Uppercasing these additions would also make them look less of an afterthought.)
I also did a quick benchmark of v6 and found the slowdown to be
smaller after the change made in build_simple_rel()
Test 1 = explain select 1;
Unpatched:
$ pgbench -n -f bench.sql -T 60 postgres
tps = 30259.096585 (excluding connections establishing)
tps = 30094.533610 (excluding connections establishing)
tps = 30124.154255 (excluding connections establishing)
Patched:
tps = 29667.414788 (excluding connections establishing)
tps = 29555.325522 (excluding connections establishing)
tps = 29101.083145 (excluding connections establishing)
(2.38% down)
Test 2 = select 1;
Unpatched:
tps = 36535.991023 (excluding connections establishing)
tps = 36568.604011 (excluding connections establishing)
tps = 35938.923066 (excluding connections establishing)
Patched:
tps = 35187.363260 (excluding connections establishing)
tps = 35166.993210 (excluding connections establishing)
tps = 35436.486315 (excluding connections establishing)
(2.98% down)
As far as I can see the patch is ready to go, but I'll defer to Mark,
who's also listed on the reviewer list for this patch.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-15 00:17:24 | Re: "SELECT ... FROM DUAL" is not quite as silly as it appears |
Previous Message | Tom Lane | 2019-01-15 00:10:57 | Re: [HACKERS] Surjective functional indexes |