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
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 |