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, but artificially trying to
>> flatten that
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 to be confusing, not
> h
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 have a meaningful valu
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
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 tha
* 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 confusion
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 w
* 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 expends extra effort
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 reasonable.
It's sti
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 mentioned in the docs, I think
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
> have ANALYZE spit out "N/A
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
have ANALYZE spit out "N/A" instead of 0 for these nod
12 matches
Mail list logo