Re: [HACKERS] Fixing matching of boolean index columns to sort ordering - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Fixing matching of boolean index columns to sort ordering
Date
Msg-id CAB7nPqSwSuA2n9EJKpEsyaDJcMMXckCpyvQwRUedA5fTq2RgKA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Fixing matching of boolean index columns to sort ordering  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Fixing matching of boolean index columns to sort ordering  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 13, 2017 at 10:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] PSQL commands: \quit_if, \quit_unless
Next
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support