Re: index-only count(*) for indexes supporting bitmap scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: index-only count(*) for indexes supporting bitmap scans
Date: 2017-04-12 14:24:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> writes:
> With planner, the changes are more complex. Two things must be done
> there. First, when the tlist is empty, we must use a different cost
> function for bitmap heap scan, because the heap access pattern is
> different. Second, choose_bitmap_and() must use a different algorithm
> for choosing the right combination of paths. A standard algorithm
> chooses the combination based on cost. For count(*) purposes, the
> decisive factor is that the path has to check all the restrictions, or
> else we'll need heap access to recheck some of them, which defeats the
> purpose of having this optimization. The planner code that builds and
> costs the index path is fairly complex, and integrating this additional
> behavior into it didn't look good to me.

TBH, I'm not sure you need to do any of that work. Have you got evidence
that the planner will fail to choose the right plan regardless? I'm
particularly unconvinced that choose_bitmap_and is a critical problem,
because once you're into having to AND multiple indexes, you're talking
about an expensive query anyhow.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2017-04-12 14:24:56 Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Previous Message Tom Lane 2017-04-12 14:12:47 Cutting initdb's runtime (Perl question embedded)