Andrew Gierth <and...@tao11.riddles.org.uk> writes: > "Alexander" == Alexander Kuzmenkov <a.kuzmen...@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