Michael Paquier writes:
> 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".
Pushed,
On Fri, Jan 13, 2017 at 10:29 PM, Tom Lane wrote:
> Michael Paquier 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
Michael Paquier 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 *
On Wed, Dec 14, 2016 at 12:18 AM, David G. Johnston
wrote:
> On Mon, Dec 12, 2016 at 10:08 PM, Tom Lane wrote:
>>
>> Every WHERE clause is a
>>
>> boolean expression, so there's no principled reason why such a rule
>> wouldn't result in canonicalizing e.g. "i = 42" into "(i = 42) = true",
>> wrea
On Mon, Dec 12, 2016 at 10:08 PM, Tom Lane wrote:
> Every WHERE clause is a
>
boolean expression, so there's no principled reason why such a rule
> wouldn't result in canonicalizing e.g. "i = 42" into "(i = 42) = true",
> wreaking havoc on every other optimization we have. Restricting it
> to on
The attached patch addresses the complaint raised in
https://www.postgresql.org/message-id/CAHt_Luuao4gd6De61GryK=2ff-mtghzjqffdjz02usdvqym...@mail.gmail.com
namely, that if you have an index on, say, integer columns i and j,
then the planner will figure out that it can use an indexscan with
no ad
