Re: [HACKERS] Fixing matching of boolean index columns to sort ordering
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Fixing matching of boolean index columns to sort ordering |
Дата | |
Msg-id | CAB7nPqSwSuA2n9EJKpEsyaDJcMMXckCpyvQwRUedA5fTq2RgKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Fixing matching of boolean index columns to sort ordering (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Fixing matching of boolean index columns to sort ordering
|
Список | 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 по дате отправления: