Re: improve transparency of bitmap-only heap scans

From: James Coleman <jtc331(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, Emre Hasegeli <emre(at)hasegeli(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: improve transparency of bitmap-only heap scans
Date: 2020-03-20 01:38:46
Message-ID: CAAaqYe_PT+EGmdC+pQgJhPZD+bfN3nn7GPq8riVYZCu6bWeO5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 19, 2020 at 9:26 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> 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 exp where a between 25 and 35 and d between 5 and 10;
> Finalize Aggregate (cost=78391.68..78391.69 rows=1 width=8) (actual time=525.972..525.972 rows=1 loops=1)
> -> Gather (cost=78391.47..78391.68 rows=2 width=8) (actual time=525.416..533.133 rows=3 loops=1)
> Workers Planned: 2
> Workers Launched: 2
> -> Partial Aggregate (cost=77391.47..77391.48 rows=1 width=8) (actual time=518.406..518.406 rows=1 loops=3)
> -> Parallel Bitmap Heap Scan on exp (cost=31825.37..77245.01 rows=58582 width=0) (actual time=296.309..508.440 rows=43887 loops=3)
> Recheck Cond: ((a >= 25) AND (a <= 35) AND (d >= 5) AND (d <= 10))
> Heap Blocks: unfetched=4701 exact=9650
> -> BitmapAnd (cost=31825.37..31825.37 rows=140597 width=0) (actual time=282.590..282.590 rows=0 loops=1)
> -> Bitmap Index Scan on index_exp_a (cost=0.00..15616.99 rows=1166456 width=0) (actual time=147.036..147.036 rows=1099872 loops=1)
> Index Cond: ((a >= 25) AND (a <= 35))
> -> Bitmap Index Scan on index_exp_d (cost=0.00..16137.82 rows=1205339 width=0) (actual time=130.366..130.366 rows=1200000 loops=1)
> Index Cond: ((d >= 5) AND (d <= 10))
>
>
> > +++ b/src/backend/commands/explain.c
> > @@ -2777,6 +2777,8 @@ show_tidbitmap_info(BitmapHeapScanState *planstate, ExplainState *es)
> > {
> > if (es->format != EXPLAIN_FORMAT_TEXT)
> > {
> > + ExplainPropertyInteger("Unfetched Heap Blocks", NULL,
> > + planstate->unfetched_pages, es);
> > ExplainPropertyInteger("Exact Heap Blocks", NULL,
> > planstate->exact_pages, es);
> > ExplainPropertyInteger("Lossy Heap Blocks", NULL,
> > @@ -2784,10 +2786,14 @@ show_tidbitmap_info(BitmapHeapScanState *planstate, ExplainState *es)
> > }
> > else
> > {
> > - if (planstate->exact_pages > 0 || planstate->lossy_pages > 0)
> > + if (planstate->exact_pages > 0 || planstate->lossy_pages > 0
> > + || planstate->unfetched_pages > 0)
> > {
> > ExplainIndentText(es);
> > appendStringInfoString(es->str, "Heap Blocks:");
> > + if (planstate->unfetched_pages > 0)
> > + appendStringInfo(es->str, " unfetched=%ld",
> > + planstate->unfetched_pages);
> > if (planstate->exact_pages > 0)
> > appendStringInfo(es->str, " exact=%ld", planstate->exact_pages);
> > if (planstate->lossy_pages > 0)

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 is parsing it, and because bitmap-only is a relatively new
> feature. Its output is probably less common than exact/lossy.

I tweaked that (and a comment that didn't reference the change); see attached.

James

Attachment Content-Type Size
v4-0001-Show-bitmap-only-unfetched-page-count-to-EXPLAIN.patch text/x-patch 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2020-03-20 01:41:54 Re: Add A Glossary
Previous Message Justin Pryzby 2020-03-20 01:26:07 Re: improve transparency of bitmap-only heap scans