Would it be a good idea to add TRACK_IO_TIMING as an option to @PostgreSQL's EXPLAIN which would override the GUC?
#3 means EXPLAIN options are already becoming a big mess (not allowed enough characters for that).
Please retweet after voting.
-
-
Replying to @pg_xocolatl @PostgreSQL
I’d rather we just change the default to be on, or maybe check at initdb time if we think it would be an issue or not and enable it then. We have the tooling to run that test and check in pg_test_timing...
1 reply 0 retweets 0 likes -
That seems like a separate discussion to to me. Independent on the GUC being enabled by default, it's still quite worthwhile to be able to control EXPLAIN ANALYZE's overhead with options like this.
1 reply 0 retweets 0 likes -
The overhead is negligible in nearly all cases, we only don’t have it enabled by default because on some platforms, most of which are gone now, it can be expensive...
1 reply 0 retweets 0 likes -
It's really not negligible when you either have fast IO and do a lot of IO, or rely on the kernel side page cache. Even on a modern platform. The overhead of EXPLAIN's TIMING is obviously higher - that's why it's OK to implicitly turn in on in EXPLAIN ANALYZE.
1 reply 1 retweet 0 likes -
Replying to @AndresFreundTec @net_snow and
I see like a repeatable ~0.5% overhead of io timing being enabled, and a 0.9% overhead when *disabling* all the intel "make your processor slower" safety measures.
1 reply 0 retweets 1 like
To be clear, I think we probably should enable it by default. Just think it's a) not free b) a separate discussion from having an EXPLAIN knob.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.