|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> I ran a few benchmarks on an AWS m5d.large instance based on top of
> c5c7fa261f5. The biggest regression I see is from a simple SELECT 1 at
> around 5-6%. A repeat of your test of SELECT 2+2 showed about half
> that regression so the simple addition function call is introducing
> enough overhead to lower the slowdown percentage by a good amount.
I can reproduce a small slowdown on "SELECT 1;", though for me it's
circa 2% not 5-6%. I'm not entirely sure that's above the noise level
--- I tend to see variations of that size even from unrelated code
changes. But to the extent that it's real, it seems like it must be
coming from one of these places:
* replace_empty_jointree adds a few pallocs for the new RTE and
* After subquery_planner calls replace_empty_jointree, subsequent
places that loop over the rtable will see one entry instead of none.
They won't do much of anything with it, but it's a few more cycles.
* remove_useless_result_rtes is new code; it won't do much in this
case either, but it still has to examine the jointree.
* query_planner() does slightly more work before reaching its fast-path
None of these are exactly large costs, and it's hard to get rid of
any of them without ugly code contortions. I experimented with
micro-optimizing the trivial case in remove_useless_result_rtes,
but it didn't seem to make much difference for "SELECT 1", and it
would add cycles uselessly in all larger queries.
I also noticed that I'd been lazy in adding RTE_RESULT support to
build_simple_rel: we can save a couple of palloc's if we give it its own
code path. That did seem to reduce the penalty a shade, though I'm
still not sure that it's above the noise level.
> 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.
Anyway, herewith v6, rebased up to HEAD, with the build_simple_rel
improvement and the regression test fix I mentioned earlier.
regards, tom lane
|Next Message||Alvaro Herrera||2019-01-14 20:55:44||Re: Reducing header interdependencies around heapam.h et al.|
|Previous Message||Tomas Vondra||2019-01-14 19:21:45||Re: [HACKERS] PATCH: multivariate histograms and MCV lists|