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

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: index-only count(*) for indexes supporting bitmap scans
Date: 2017-04-12 10:38:05
Message-ID: 87ziflvryn.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Alexander" == Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> writes:

Alexander> Structurally, the patch consists of two major parts: a
Alexander> specialized executor node

Why?

It strikes me that the significant fact here is not that we're doing
count(*), but that we don't need any columns from the bitmap heap scan
result. Rather than creating a whole new node, can't the existing
bitmap heapscan be taught to skip fetching the actual table page in
cases where it's all-visible, not lossy, and no columns are needed?

(this would also have the advantage of getting parallelism for free)

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2017-04-12 11:19:52 Re: [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
Previous Message Amit Langote 2017-04-12 10:29:31 Re: pg_dump emits ALTER TABLE ONLY partitioned_table