On Fri, Jan 13, 2017 at 10:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: >> And actually, contrary to what is mentioned upthread, the planner is >> not able to avoid a sort phase if other data types are used, say: >> =# create table foo (a int, b int); >> CREATE TABLE >> =# create index on foo (a, b); >> CREATE INDEX >> =# explain (costs off) select * from foo where a = 1 order by b limit 10; > > No, there's a difference between "not able to" and "chooses not to". > In this example case, it just thinks a bitmap scan is cheaper than > an ordered scan: > > The problem with the boolean-column case is it fails to recognize > that the index matches at all.
Bah. I was sure I was missing something, still I would have thought that the index scan is cheaper than the bitmap index scan with ORDER BY. As far as I can see, this patch is not the most elegant thing, but it has value. So marked as "ready for committer". -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
