Tom Lane wrote:
but this behavior isn't reproduced in the later message, so I wonder if
it wasn't an artifact of something else taking a chunk of time.
I think is due the fact that first queries were performed in peakhours.
Regards
Gaetano Mendola
---(end of
Quoting Tom Lane [EMAIL PROTECTED]:
Klint Gore [EMAIL PROTECTED] writes:
Is having an order by in a view legal?
Not according to the SQL spec, but PG has allowed it for several releases.
(The same goes for ORDER BY in a sub-select, which is actually pretty
much the same thing ...)
Umm...
Gaetano Mendola [EMAIL PROTECTED] writes:
If you need other info in order to improve the planner,
... like, say, the PG version you are using, or the definitions of the
views involved? It's difficult to say much of anything about this.
However: the reason the second plan wins is because there
Tom Lane wrote:
However: the reason the second plan wins is because there are zero rows
fetched from sat_request, and so the bulk of the plan is never executed
at all. I doubt the second plan would win if there were any matching
sat_request rows.
That's what I thought at first, but if you look
David Brown [EMAIL PROTECTED] writes:
The planner is not breaking up the outer join in his v_packages view:
The planner doesn't make any attempt to rearrange join order of outer
joins. There are some cases where such a rearrangement is OK, but there
are other cases where it isn't, and we don't
