From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | emre(at)hasegeli(dot)com, Oleksii Kliukin <alexk(at)hintbits(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: rows estimate in explain analyze for the BRIN index |
Date: | 2015-12-30 23:23:37 |
Message-ID: | 32048.1451517817@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> We do already have a nearby precedent for returning zero when we don't
>> have an accurate answer: that's what BitmapAnd and BitmapOr plan nodes
>> do. (This is documented btw, at the bottom of section 14.1.)
> Hmm, but amgetbitmap is documented thusly:
> The number of tuples fetched is returned (this might be just an
> approximate count, for instance some AMs do not detect
> duplicates).
> http://www.postgresql.org/docs/9.5/static/index-functions.html
> so I'm not sure we're actually violating an expectation that the number
> of rows is exact. I mean, if we zero out this one, shouldn't we set it
> to zero for these other documented cases too?
Well, the code comments may say that, but the user-facing docs don't ...
More generally, people are accustomed to the idea that the planner's
estimated rowcounts are just estimates, but they're not accustomed to
the idea that the runtime "actual" rowcounts might be just estimates.
That seems like it's moving EXPLAIN ANALYZE's contract quite a bit,
even if there are some documents for internal APIs that say something
else.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2015-12-30 23:47:19 | Re: pg_hba_lookup function to get all matching pg_hba.conf entries |
Previous Message | Alvaro Herrera | 2015-12-30 22:59:00 | Re: rows estimate in explain analyze for the BRIN index |