Tom Lane wrote:
Your idea of reducing id_provider to id_class using a separate query
seems like a good one to me --- that will allow the planner to generate
different plans depending on which id_class value is involved.
However is not a natural way to approch the problem;
Am I wrong ?
Gaetano
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> What about the wrong row expected ?
After I looked more closely, I realized that the planner hasn't any hope
of getting a really correct answer on that. You've got
WHERE ... ud.id_class = cd.id_class AND
cd.id_provider
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
The select take long:
Postgres7.3.3: average 4000 ms
Postgres7.4b2: average 2600 ms
you can experiment your self with the dump that I gave you
Hm. I tried to duplicate your results. I'm getting about 5400 msec
versus 4200 msec, whic
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> The select take long:
> Postgres7.3.3: average 4000 ms
> Postgres7.4b2: average 2600 ms
> you can experiment your self with the dump that I gave you
Hm. I tried to duplicate your results. I'm getting about 5400 msec
versus 4200 msec, which is a nic
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. P
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> The default_statistics_target was already 1000 for
> postgres7.4beta2 and after setting this value to 1000
> for postgres7.3.3 I had the same explain with the same
> expected row ( almost 400 ) and the almost the same time execution.
Hmph. Can you loo
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, it sure looks to be exactly the same plan. The performance
>> difference seems to be just that the seqscans are faster. I surmise
>> that in the 7.3 database you had a lot of dead rows, or at least a lot
>> of free space. Possi
Gaetano Mendola wrote:
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. Possibly you need to vacuum more often
Tom Lane wrote:
Hm, it sure looks to be exactly the same plan. The performance
difference seems to be just that the seqscans are faster. I surmise
that in the 7.3 database you had a lot of dead rows, or at least a lot
of free space. Possibly you need to vacuum more often to keep down the
amount
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> = Bad news =
> I posted time ago about a slow query:
> SELECT ul.*
> FROM user_logs ul,
> user_data ud,
> class_default cd
> WHERE ul.id_user = ud.id_user AND
>ud.id_class = cd.id_class AND
>cd.id_provider = 39;
I t
Hi all,
my impression on 7.4 performances:
= Good news =
How expected the use of clausole 'IN' with Postgres 7.4beta2
now is really fast ( see the result below )
= Bad news =
I posted time ago about a slow query:
SELECT ul.*
FROM user_logs ul,
user_data ud,
class_defaul
11 matches
Mail list logo
