From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | "Tobias Florek *EXTERN*" <postgres(at)ibotty(dot)net>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: tuple compare involving NULL |
Date: | 2014-08-13 15:00:16 |
Message-ID: | 19993.1407942016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
> Tobias Florek wrote:
>> maybe a little more context might be helpful. i am trying to have
>> reasonable efficient paging. the query i am building looks like
>>
>> select t.*
>> from table t,
>> (select a, b from table where id = ) q
>> where (q.a, t.b, t.id) > (t.a, q.b, q.id)
>> order by t.a desc, t.b asc, t.id asc
>> limit 10;
>>
>> where t is a table with column id (primary key, serial), a and b.
>>
>> that works fine and efficient (given an index (a,b) on t) without NULLs,
>> but (predictably) not in the presence of NULLs.
>>
>> i would certainly like to handle that better, but i don't have any ideas
>> besides manually expanding the tuple comparison.
> That would probably make it harder to use a multicolumn index correctly.
Yeah, if you change the WHERE condition at all, it will stop matching
the multicolumn index.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tob | 2014-08-13 15:24:40 | Re: tuple compare involving NULL |
Previous Message | David G Johnston | 2014-08-13 14:58:33 | Re: tuple compare involving NULL |