On Tue, Nov 1, 2016 at 9:46 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> 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 to be confusing, not
>> helpful.  (Just last week I saw a case where the fact that many pages
>> were being lossified caused a performance problem ... so treating
>> lossy pages as if they don't exist would have led to a lot of
>> head-scratching, because under Tom's proposal the row count would have
>> been way off.)
> It would very often be the case that the value I suggested would be exact,
> so this complaint seems off-base to me.

>From my point of view, something that very often gives the right
answers isn't acceptable.  We certainly wouldn't accept a query
optimization that very often gives the right answers.  It's gotta
always give the right answer.

> If we were willing to add an additional output line, we could also report
> the number of lossy pages in the result bitmap, and people would then
> know not to trust the reported rowcount as gospel.  But it's still useful
> to have it.  I'm envisioning output like
>    ->  BitmapOr  (cost=... rows=2000 width=0) (actual time=... rows=1942 
> loops=1)
> in the no-lossy-pages case, otherwise
>    ->  BitmapOr  (cost=... rows=4000 width=0) (actual time=... rows=3945 
> loops=1)
>          Lossy Bitmap: exact entries=2469, lossy pages=123
> There's nothing misleading about that, IMO.  (Exercise for the reader:
> what rows/page estimate did I assume?)

(4000-2469)/123 = 12.44715 ?

I think it's inherently misleading to report values that were
concocted specifically for EXPLAIN ANALYZE.  Things that we report
there should have some underlying reality or relevance.  People -
including me - tend to assume they do, and you don't want to spend
time chasing down something that's PURELY an EXPLAIN ANALYZE artifact
with no actual relevance to the runtime behavior.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to