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 will tell you exactly what happened and it's pretty easy to reason about whether rows should have gone up or down based on the type of node. You can't do that for Bitmap(And|Or) unless you know the details of how TIDBitmaps work. Reporting N/A makes it crystal clear that these nodes operate very differently than all the others.
(On a related note, it would also be nice if we reported fractional rows when the row count low and loops is high.)
That said, I'm a big fan of how we have more detail for things like a HashJoin (buckets, batches, memory usage) and it might be nice to have more information like that for a BitmapAnd (and friends). In particular, I'm thinking of memory usage, exact vs. lossy pages, etc. Knowing that the bitmap has gotten to the point of being lossy might indicate that a user could up work_mem, for example, and possibly avoid recheck costs.
I think that's the best way to handle this: report N/A in the header and then provide details on exact vs lossy. That provides a clear indication to users that these kinds of nodes are special, as well as a reminder as to why they're special. Certainly the node could report an exact rowcount in the header if there were no lossy pages too.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
