> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
