Re: [PERFORM] Query question

[Tom Lane]

Neil Conway [EMAIL PROTECTED] writes:
 Interesting -- I wonder if it would be possible for the optimizer to
 detect this and avoid the redundant inner sort ... (/me muses to
 himself)

I think the ability to generate two sort steps is a feature, not a bug.
This has been often requested in connection with user-defined
aggregates, where it's handy to be able to control the order of arrival
of rows at the aggregation function.  If the optimizer suppressed the
inner sort then we'd lose that ability.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [PERFORM] Query question

[Christopher Kings-Lynne]

The only thing you're adding to the query is a second SORT step, so it 
shouldn't require any more time/memory than the query's first SORT
did.


Interesting -- I wonder if it would be possible for the optimizer to
detect this and avoid the redundant inner sort ... (/me muses to
himself)
That's somethign I've wondered myself as well.  Also - I wonder if the 
optimiser could be made smart enough to push down the outer LIMIT and 
OFFSET clauses into the subquery.

Chris



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html