Re: Improve output of BitmapAnd EXPLAIN ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve output of BitmapAnd EXPLAIN ANALYZE
Date: 2016-10-20 23:20:07
Message-ID: 19366.1477005607@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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 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 expends extra effort to try to produce a rowcount number.

We could certainly run through the result bitmap and count the number
of exact-TID bits. I don't see a practical way of doing something
with lossy page bits, but maybe those occur infrequently enough
that we could ignore them? Or we could arbitrarily decide that
a lossy page should be counted as MaxHeapTuplesPerPage, or a bit
less arbitrarily, count it as the relation's average number
of tuples per page.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2016-10-20 23:28:09 Re: Indirect indexes
Previous Message Merlin Moncure 2016-10-20 21:53:42 Re: emergency outage requiring database restart