Hi
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
select a.* from test1 a, (select id from test1 order by num) as b where
a.id = b.id;
There is no constraint on the order of 'a', so why is pull_up_subqueries
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney [EMAIL PROTECTED] wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or distinct on clause is used in a
subquery.
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation. If you are
saying you don't want the sort to occur, why did
Bruno Wolff III wrote:
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney [EMAIL PROTECTED] wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation.
Then why spend time
Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
Tom Lane wrote:
Dennis Haney [EMAIL PROTECTED] writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to
Hannu Krosing [EMAIL PROTECTED] writes:
Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
I'm saying the sort makes no sense. So why even bother executing it?
why did you write it?
I believe the most common scenario would be that the subquery was
expanded from a view...
And why is it
As a more direct response, there *are* reasons for people to put ORDER
BY in a subselect and expect it to be honored. The typical example
that's been discussed several times in the archives is that you want to
use an aggregate function that is sensitive to the ordering of its input
Not to
Rod Taylor [EMAIL PROTECTED] writes:
As a more direct response, there *are* reasons for people to put ORDER
BY in a subselect and expect it to be honored. The typical example
that's been discussed several times in the archives is that you want to
use an aggregate function that is sensitive to
hi,
can anyone explain me why there are different query plans for select ...
from ... where y!=x and select ... from ... where yx or yx for
integers, please?
see the details below...
thanks,
kuba
db_cen7=# analyze;
ANALYZE
db_cen7=# \d ts19
Table ts19
Jakub Ouhrabka [EMAIL PROTECTED] writes:
can anyone explain me why there are different query plans for select ...
from ... where y!=x and select ... from ... where yx or yx for
integers, please?
!= isn't an indexable operation. This is not the planner's fault, but
a consequence of the index
11 matches
Mail list logo
