From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Greg Stark <stark(at)mit(dot)edu>, Lukas Fittl <lukas(at)fittl(dot)com>, pryzby(at)telsasoft(dot)com |
Subject: | Re: [PATCH] Add extra statistics to explain for Nested Loop |
Date: | 2022-07-31 03:49:39 |
Message-ID: | 20220731034939.4ctdylvy72bl5ozy@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 30, 2022 at 08:54:33PM +0800, Julien Rouhaud wrote:
>
> It turns out that having pg_stat_statements with INSTRUMENT_EXTRA indirectly
> requested by INSTRUMENT_ALL adds a ~27% overhead.
>
> I'm not sure that I actually believe these results, but they're really
> consistent, so maybe that's real.
>
> Anyway, even if the overheadwas only 1.5% like in your own benchmark, that
> still wouldn't be acceptable. Such a feature is in my opinion very welcome,
> but it shouldn't add *any* overhead outside of EXPLAIN (ANALYZE, VERBOSE).
I did the same benchmark this morning, although trying to stop all background
jobs and things on my machine that could interfere with the results, using
longer runs and more runs and I now get a reproducible ~1% overhead, which is
way more believable. Not sure what happened yesterday as I got reproducible
number doing the same benchmark twice, I guess that the fun doing performance
tests on a development machine.
Anyway, 1% is in my opinion still too much overhead for extensions that won't
get any extra information.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-07-31 04:11:36 | Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger |
Previous Message | Thomas Munro | 2022-07-31 03:46:33 | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |