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 som
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 conn
Josh Berkus <[EMAIL PROTECTED]> writes:
> 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 inn
Chris,
> SELECT * FROM (arbitrary subquery) AS sub ORDER BY 1,3;
>
> Now, this all works fine, but I want to know if this is efficient or not.
>
> Does doing a select of a select cause serious performance degradation?
It would be better if you could strip out the inner sort, but I can understand
Hi,
I have coded some improvements to phpPgAdmin that I think are pretty
cool. Basicaly, once you are browsing the results of an arbitrary
SELECT query, you can still sort by columns, regardless of the
underlying ORDER BY of the SELECT.
I do this like this:
SELECT * FROM (arbitrary subquery)
