*Hi all !
Postgresql (8.2) has as a strange behaviour in some of my environments.
*
*A request follows two execution plans ( but not always !!! ). I encounter
some difficulties to reproduce the case.*
*J-2*
Aggregate (*cost=2323350.24..2323350.28 rows=1 width=24*)
- Merge Join
Hi, and why do you think this is a problem?
The explain plan is expected to change for different parameter values,
that's OK. The merge in the first query is expected to produce
significantly more rows (91774) than the other one (229). That's why the
second query chooses nested loop instead of
I've already used an 'EXPLAIN ANALYZE' to post the message. So I don't
clearly understand what you are expecting for, when you tell me to provide
'EXPLAIN ANALYZE' (please excuse me for the misunderstood)
I agree with you when you say that for two different values, the costs will
be different.
I've already used an 'EXPLAIN ANALYZE' to post the message. So I don't
clearly understand what you are expecting for, when you tell me to provide
'EXPLAIN ANALYZE' (please excuse me for the misunderstood)
No, you haven't. You've provided 'EXPLAIN' output, but that just prepares
an execution
Sorry ! The command I use is 'EXPLAIN ANALYZE'
I can't do better ...
2011/3/1 t...@fuzzy.cz
I've already used an 'EXPLAIN ANALYZE' to post the message. So I don't
clearly understand what you are expecting for, when you tell me to
provide
'EXPLAIN ANALYZE' (please excuse me for the
Me again ! I have checked this question of 'explain analyze' and I
understand now.
When the problem occured I have run a 'EXPLAIN'
I have run the request again to open this case using 'EXPLAIN ANALYZE' but I
didn't reproduce the case. That's why I sent the other trace but it doesn't
countain
Marc Cousin cousinm...@gmail.com writes:
Le mardi 01 mars 2011 07:20:19, Tom Lane a écrit :
It's worth pointing out that the only reason this effect is dominating
the runtime is that you don't have any statistics for these toy test
tables. If you did, the cycles spent using those entries
2011/2/4 Mladen Gogala mladen.gog...@vmsinfo.com:
Віталій Тимчишин wrote:
Hi, all.
All this optimizer vs hint thread
There is no optimizer vs. hint. Hints are a necessary part of the
optimizer in all other databases. Without hints Postgres will not get used
in the company that I work for,
The Tuesday 01 March 2011 16:33:51, Tom Lane wrote :
Marc Cousin cousinm...@gmail.com writes:
Le mardi 01 mars 2011 07:20:19, Tom Lane a écrit :
It's worth pointing out that the only reason this effect is dominating
the runtime is that you don't have any statistics for these toy test
On Tue, Mar 1, 2011 at 4:44 AM, Joby Joba jobyjob...@gmail.com wrote:
Me again ! I have checked this question of 'explain analyze' and I
understand now.
When the problem occured I have run a 'EXPLAIN'
I have run the request again to open this case using 'EXPLAIN ANALYZE' but I
didn't
I wrote:
Marc Cousin cousinm...@gmail.com writes:
Yes, for the same test case, with a bit of data in every partition and
statistics up to date, planning time goes from 20 seconds to 125ms for the
600
children/1000 columns case. Which is of course more than acceptable.
[ scratches head
Hi, appreciated mailing list. Thanks already for taking your time for my
performance question. Regards, Sander.
===POSTGRESQL VERSION AND ORIGIN===
PostgreSQL 8.3.9 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.4
(Ubuntu 4.2.4-1ubuntu3)
Installed using apt-get install postgresql-8.3
===A
On 03/01/2011 06:14 PM, sverhagen wrote:
Hi, appreciated mailing list. Thanks already for taking your time for my
performance question. Regards, Sander.
===POSTGRESQL VERSION AND ORIGIN===
PostgreSQL 8.3.9 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.4
(Ubuntu 4.2.4-1ubuntu3)
Installed
13 matches
Mail list logo
