From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Composite Datums containing toasted fields are a bad idea(?) |
Date: | 2014-04-25 16:05:17 |
Message-ID: | 8528.1398441917@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> The case I am worried most about is queries like:
> SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> I've seen such generated by a some query generators for paging. But I
> guess that's something we're going to have to accept.
Meh ... is it likely that the columns involved in an ordering comparison
would be so wide as to be toasted out-of-line? Such a query would only be
fast if the row value were indexed, which would pretty much preclude use
of wide columns.
I'm actually more worried about the function-returning-tuple case, as that
might bite people who thought they'd use some cute functional notation or
other and it wouldn't cost 'em anything.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-04-25 16:25:44 | Re: Composite Datums containing toasted fields are a bad idea(?) |
Previous Message | Andres Freund | 2014-04-25 15:37:40 | Re: Composite Datums containing toasted fields are a bad idea(?) |