From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: tuple compare involving NULL |
Date: | 2014-08-13 14:44:14 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B17D2876D@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
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.
The best solution would probably be to set the relevant fields NOT NULL.
NULLs usually make things harder on the database side.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brusselback | 2014-08-13 14:51:51 | Need a sanity check with EAV |
Previous Message | Tobias Florek | 2014-08-13 14:28:42 | Re: tuple compare involving NULL |