Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-11-01 Thread Robert Haas
On Tue, Nov 1, 2016 at 9:46 AM, Tom Lane wrote: > Robert Haas writes: >> I don't like Tom's proposal of trying to fake up a value here when >> EXPLAIN ANALYZE is in use. Reporting "exact" and "lossy" values for >> BitmapAnd would be a fine enhancement,

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-11-01 Thread Tom Lane
Robert Haas writes: > I don't like Tom's proposal of trying to fake up a value here when > EXPLAIN ANALYZE is in use. Reporting "exact" and "lossy" values for > BitmapAnd would be a fine enhancement, but artificially trying to > flatten that back into a row count is going

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-11-01 Thread Robert Haas
On Mon, Oct 31, 2016 at 6:56 AM, Emre Hasegeli wrote: > The BRIN Bitmap Index Scan has the same problem. I have seen people > confused by this. I think N/A would clearly improve the situation. I agree. Or perhaps better still, leave rows=%.0f out altogether when we don't

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-31 Thread Emre Hasegeli
The BRIN Bitmap Index Scan has the same problem. I have seen people confused by this. I think N/A would clearly improve the situation. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-21 Thread Jim Nasby
On 10/21/16 12:30 PM, Stephen Frost wrote: I don't see why we would want to stick 'N/A' in for the header, even if we are reporting the details, when we can provide a pretty reasonable number. Because then it's absolutely clear that we don't have a valid rowcount, only a guess (and a guess

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-21 Thread Stephen Frost
* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 10/21/16 8:21 AM, Stephen Frost wrote: > >Counting each page as the relation's average number of tuples per page > >seems entirely reasonable to me, for what that is trying to report. > > My concern is that still leaves a lot of room for

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-21 Thread Jim Nasby
On 10/21/16 8:21 AM, Stephen Frost wrote: Counting each page as the relation's average number of tuples per page seems entirely reasonable to me, for what that is trying to report. My concern is that still leaves a lot of room for confusion when interpreting EXPLAIN ANALYZE. Every other node

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-21 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Changing it in a new major release seems entirely reasonable. > > It's still a crock though. I wonder whether it wouldn't be better to > change the nodeBitmap code so that when EXPLAIN ANALYZE is active, > it

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-20 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> That would break code that tries to parse that stuff, eg depesz.com. > I don't believe Jim was suggesting that we back-patch such a change. I don't either. > Changing it in a new major release seems entirely

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-20 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Jim Nasby writes: > > A customer just pinged me wondering how it was that a BitmapAnd node was > > reporting 0 tuples when the Bitmap Heap Scan above it showed it had in > > fact generated tuples. > > > While this is

Re: [HACKERS] Improve output of BitmapAnd EXPLAIN ANALYZE

2016-10-20 Thread Tom Lane
Jim Nasby writes: > A customer just pinged me wondering how it was that a BitmapAnd node was > reporting 0 tuples when the Bitmap Heap Scan above it showed it had in > fact generated tuples. > While this is mentioned in the docs, I think it would be very helpful to >