Avoid displaying unnecessary "Recheck Cond" in EXPLAIN ANALYZE output if the bitmap is non-lossy

Started by Bharath Rupireddyover 5 years ago2 messageshackers
Jump to latest
#1Bharath Rupireddy
bharath.rupireddyforpostgres@gmail.com

Hi,

As specified in $subject, if the bitmap constructed by bitmap index
scan is non-lossy i.e. row-level bitmap, then showing "Recheck Cond"
in EXPLAIN ANALYZE output is pointless. However in EXPLAIN without
ANALYZE we can't say the bitmap is actually a non-lossy one, as we
don't actually construct the "original" bitmap, so showing "Recheck
Cond" in this case makes sense.

Attaching a small patch that corrects EXPLAIN ANALYZE output for bitmap scans.

Note: $subject is identified in [1]https://www.youtube.com/watch?v=UXKYAZOWDgk ---> at 13:50 (mm:ss).

Thoughts?

[1]: https://www.youtube.com/watch?v=UXKYAZOWDgk ---> at 13:50 (mm:ss)

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

Attachments:

v1-Avoid-displaying-unnecessary-Recheck-Cond-when-th.patchapplication/x-patch; name=v1-Avoid-displaying-unnecessary-Recheck-Cond-when-th.patchDownload+14-33
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bharath Rupireddy (#1)
Re: Avoid displaying unnecessary "Recheck Cond" in EXPLAIN ANALYZE output if the bitmap is non-lossy

Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:

As specified in $subject, if the bitmap constructed by bitmap index
scan is non-lossy i.e. row-level bitmap, then showing "Recheck Cond"
in EXPLAIN ANALYZE output is pointless. However in EXPLAIN without
ANALYZE we can't say the bitmap is actually a non-lossy one, as we
don't actually construct the "original" bitmap, so showing "Recheck
Cond" in this case makes sense.

I do not think this change makes even a little bit of sense.
The recheck condition is part of the plan structure, it is not
execution statistics.

I compare this proposal to having EXPLAIN suppress plan tree nodes
entirely if they weren't executed. We don't do that and it
wouldn't be an improvement. Especially not for non-text output
formats, where the schema of fields that are presented ought to
be fixed for any given plan tree.

regards, tom lane