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 ..
Gaetano Mendola wrote:
I think is due the fact that first queries were performed in peakhours.
A memory intensive operation takes 7.5 times longer during heavy loads.
Doesn't this suggest that swapping of working memory is occurring?
---(end of broadcast)-
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 broad
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'
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 mor
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 ...)
> If so, does it do 2 sorts when you sort by so
On Sun, 20 Feb 2005 13:46:10 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> sat_request rows. If this is the case you actually need to optimize,
> probably the thing to do is to get rid of the ORDER BY clauses you
> evidently have in your views, so that there's some chance of building
> a fast-start
Tom Lane wrote:
> 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.
That is true, sorry I forgot
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 ther
Hi all,
I'm stuck in a select that use the hash join where should not:
6 seconds vs 0.3 ms !!
If you need other info in order to improve the planner,
let me know.
Regards
Gaetano Mendola
empdb=# explain analyze SELECT id_sat_request
empdb-#FROM sat_request sr,
empdb-# v_sc_package
10 matches
Mail list logo