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 u
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"
===
I wrote:
> Marc Cousin 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 ... ] Actual
On Tue, Mar 1, 2011 at 4:44 AM, Joby Joba 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 reproduce the case.
The Tuesday 01 March 2011 16:33:51, Tom Lane wrote :
> Marc Cousin 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
2011/2/4 Mladen Gogala :
> Віталій Тимчишин 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, period. I
Marc Cousin 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 would dwarf
>> th
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 the
Sorry ! The command I use is 'EXPLAIN ANALYZE'
I can't do better ...
2011/3/1
> > 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'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
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. Bu
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 mer
*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 (cost=2214044
13 matches
Mail list logo
