On Mon, Mar 30, 2020 at 9:59 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
> >> I'm curious if Tom's objection is mostly on the grounds that we should
> >> be consistent in what's displayed, or that he thinks the information
> >> is likely to
Amit Kapila writes:
> On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
>> I'm curious if Tom's objection is mostly on the grounds that we should
>> be consistent in what's displayed, or that he thinks the information
>> is likely to be useless.
> Yeah, it would be good if he clarifies his po
On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
>
> On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila wrote:
> >
> > Yeah, I also see this information could be useful. It seems Tom Lane
> > is not entirely convinced of this. I am not sure if this is the right
> > time to seek more opinions as we
On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila wrote:
>
> On Wed, Mar 25, 2020 at 5:44 PM James Coleman wrote:
> >
> > On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
> > > >
> > > > I took a quick look through this patch. Whil
On Wed, Mar 25, 2020 at 5:44 PM James Coleman wrote:
>
> On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila wrote:
> >
> > On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
> > >
> > > I took a quick look through this patch. While I see nothing to complain
> > > about implementation-wise, I'm a bit be
On Tue, Mar 24, 2020 at 11:02 PM Amit Kapila wrote:
>
> On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
> >
> > I took a quick look through this patch. While I see nothing to complain
> > about implementation-wise, I'm a bit befuddled as to why we need this
> > reporting when there is no compar
On Wed, Mar 25, 2020 at 12:44 AM Tom Lane wrote:
>
> I took a quick look through this patch. While I see nothing to complain
> about implementation-wise, I'm a bit befuddled as to why we need this
> reporting when there is no comparable data provided for regular index-only
> scans. Over there, y
I took a quick look through this patch. While I see nothing to complain
about implementation-wise, I'm a bit befuddled as to why we need this
reporting when there is no comparable data provided for regular index-only
scans. Over there, you just get "Heap Fetches: n", and the existing
counts for b
On Tue, Mar 24, 2020 at 1:24 AM Amit Kapila wrote:
>
> On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
> >
> > Awesome, thanks for confirming with an actual plan.
> >
> > > I don't think it matters in nontext mode, but at least in text mode, I
> > > think
> > > maybe the Unfetched blocks sh
On Tue, Mar 24, 2020 at 11:36 AM Justin Pryzby wrote:
>
> On Tue, Mar 24, 2020 at 10:54:05AM +0530, Amit Kapila wrote:
> > On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
> > >
> > > Awesome, thanks for confirming with an actual plan.
> > >
> > > > I don't think it matters in nontext mode, b
On Tue, Mar 24, 2020 at 10:54:05AM +0530, Amit Kapila wrote:
> On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
> >
> > Awesome, thanks for confirming with an actual plan.
> >
> > > I don't think it matters in nontext mode, but at least in text mode, I
> > > think
> > > maybe the Unfetched bl
On Fri, Mar 20, 2020 at 7:09 AM James Coleman wrote:
>
> Awesome, thanks for confirming with an actual plan.
>
> > I don't think it matters in nontext mode, but at least in text mode, I think
> > maybe the Unfetched blocks should be output after the exact and lossy
> > blocks,
> > in case someone
On Thu, Mar 19, 2020 at 9:26 PM Justin Pryzby wrote:
>
> On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote:
> > Does the original optimization cover parallel bitmap heap scans like this?
>
> It works for parallel bitmap only scans.
>
> template1=# explain analyze select count(*) from e
On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote:
> Does the original optimization cover parallel bitmap heap scans like this?
It works for parallel bitmap only scans.
template1=# explain analyze select count(*) from exp where a between 25 and 35
and d between 5 and 10;
Finalize Ag
On Mon, Mar 16, 2020 at 9:08 AM James Coleman wrote:
> ...
> One question though: if I change the query to:
> explain (analyze, buffers) select count(*) from exp where a between 50
> and 100 and d between 5 and 10;
> then I get a parallel bitmap heap scan, and I only see exact heap
> blocks (see a
On Tue, Mar 10, 2020 at 12:15 PM David Steele wrote:
>
> Hi Jeff,
>
> On 2/7/20 10:22 AM, Alexey Bashtanov wrote:
> > I've changed it all to "unfetched" for at least not to call the same
> > thing differently
> > in the code and in the output, and also rebased it and fit in 80 lines
> > width limi
Hi Jeff,
On 2/7/20 10:22 AM, Alexey Bashtanov wrote:
I've changed it all to "unfetched" for at least not to call the same
thing differently
in the code and in the output, and also rebased it and fit in 80 lines
width limit.
What do you think of Alexey's updates?
Regards,
--
-David
da...@pgma
I kinda suspect one of the ressons why this got so little attention is
that it was never added to any CF.
Thanks Tomas, I've created a CF entry
https://commitfest.postgresql.org/27/2443/
Best, Alex
On Fri, Feb 07, 2020 at 03:22:12PM +, Alexey Bashtanov wrote:
Hello,
It took me a while to figure out what those names mean. "unfetched",
as you call it on the code, may be more descriptive than "avoided" for
the new label. However I think the other two are more confusing. It
may be a go
Hello,
It took me a while to figure out what those names mean. "unfetched",
as you call it on the code, may be more descriptive than "avoided" for
the new label. However I think the other two are more confusing. It
may be a good idea to change them together with this.
It'll be sad if this pa
> Looking at the discussion where the feature was added, I think changing the
> EXPLAIN just wasn't considered.
I think this is an oversight. It is very useful to have this on
EXPLAIN.
> The attached patch adds "avoided" to "exact" and "lossy" as a category
> under "Heap Blocks".
It took me a w
When bitmap-only heap scans were introduced in v11 (7c70996ebf0949b142a99)
no changes were made to "EXPLAIN". This makes the feature rather opaque.
You can sometimes figure out what is going by the output of EXPLAIN
(ANALYZE, BUFFERS), but that is unintuitive and fragile.
Looking at the discussio
22 matches
Mail list logo
