From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: index-only count(*) for indexes supporting bitmap scans
In-reply-to: <87ziflvryn.fsf@news-spur.riddles.org.uk>
References: <239a8955-c0fc-f506-026d-c837e86c827b@postgrespro.ru>
 <87ziflvryn.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Wed, 12 Apr 2017 11:38:05 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8436.1491998661.1@sss.pgh.pa.us>
Date: Wed, 12 Apr 2017 08:04:21 -0400
Message-ID: <8437.1491998661@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Alexander" == Alexander Kuzmenkov <a.kuzmenkov@postgrespro.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?

+1 ... while I hadn't actually looked at the code, it seemed to me that
anything like the optimization-as-described would be impossibly klugy
from the planner's standpoint.  Your formulation sounds lots nicer.

Detecting that no columns are needed in the executor might be a bit tricky
because of the planner's habit of inserting a "physical tlist" to avoid a
projection step.  (See also nearby discussion about custom scan planning.)
But we could fix that.  I think one rule that would make sense is to
just disable the physical-tlist substitution if the relation's targetlist
is empty --- it wouldn't be buying much in such a case anyhow.  Then the
runtime tlist for the scan node would also be empty, and away you go.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers