From: | Maciek Sakrejda <msakrejda(at)truviso(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Useless sort by |
Date: | 2010-09-13 17:24:42 |
Message-ID: | AANLkTimvCqZmvRA2r7=k3y3w9_rr8TN=n6noWJtW_71T@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I see your point, but some functions like: unique, count are not affected
> by the order of values fed, and I don't think either that unique has to
> give out the unique values in the same fed order.
Sure. You'd need additional metadata about which aggregates care about
sort order and which don't. Our system is more sensitive to this sort
of thing and so we've actually implemented this, but in the absence of
this "order-sensitive" flag, you have to assume sorts matter (or
you're leaving a *lot* of room for shooting yourself in the foot).
Even with this, it seems a little dodgy to mess up sort order in a
top-level query. Relational databases are ostensibly relational, but I
imagine in practice, it may be a toss-up in the trade-off between the
performance benefits of what you are suggesting and the breaking of
implicit non-relational behaviors that users have been taking for
granted.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-09-13 18:32:09 | Re: Major performance problem after upgrade from 8.3 to 8.4 |
Previous Message | Gaetano Mendola | 2010-09-13 17:09:11 | Re: Useless sort by |