@postgresql.org
Subject: Re: [PERFORM] strange query behavior
"Tim Jones" <[EMAIL PROTECTED]> writes:
> 18,273,008 rows in observationresults
> [ and n_distinct = 12942 ]
OK, so the estimated rowcounts are coming from those two numbers.
It's notoriously hard to get a decent
I wrote:
> It's still a bit odd that the case with two batteryidentifiers was
> estimated fairly accurately when the other wasn't; I'll go look into
> that.
For the sake of the archives: I looked into this, and it seems there's
not anything going wrong other than the bogusly small n_distinct for
o
"Tim Jones" <[EMAIL PROTECTED]> writes:
> 18,273,008 rows in observationresults
> [ and n_distinct = 12942 ]
OK, so the estimated rowcounts are coming from those two numbers.
It's notoriously hard to get a decent n_distinct estimate from a small
sample :-(, and I would imagine the number of batter
-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 6:25 PM
To: Tim Jones
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] strange query behavior
The large rowcount estimate makes it back off to a non-nestloop plan for
the outer joins, and in this situation
"Tim Jones" <[EMAIL PROTECTED]> writes:
> [ explain results ]
As best I can see, the problem is with the estimate of the size of the
inner join: for two keys we have
-> Nested Loop (cost=4.01..9410.49 rows=13 width=145) (actual
time=0.227..0.416 rows=30 loops=1)
-> Bit
Tim Jones
Subject: Re: [PERFORM] strange query behavior
From psql perform: select version();
and send us that output.
Tim Jones wrote:
> Looks like 8.1.2
>
> Tim Jones
> Healthcare Project Manager
> Optio Software, Inc.
> (770) 576-3555
>
> -Original Message-
> Fr
Looks like 8.1.2
Tim Jones
Healthcare Project Manager
Optio Software, Inc.
(770) 576-3555
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 5:37 PM
To: Tim Jones
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] strange query
"Tim Jones" <[EMAIL PROTECTED]> writes:
>> Which PG version is this exactly? Are you running with any nondefault
>> planner parameters?
> Version 8.1
8.1.what?
> Here are the planner constraints I believe we changed
> effective_cache_size and random_page_cost
Those look reasonably harmless.
M
-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 4:59 PM
To: Tim Jones
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] strange query behavior
"Tim Jones" <[EMAIL PROTECTED]> writes:
> The tables for theses queries are vacuumed and an
"Tim Jones" <[EMAIL PROTECTED]> writes:
> The tables for theses queries are vacuumed and analyzed regularly. I
> just did an analyze to be sure and here are the results
> ...
There's something pretty wacko about the choice of plan in the slow case
--- I don't see why it'd not have used the same pl
.00..1.02
rows=6 width=0) (actual time=0.032..0.032 rows=0 loops=1)
Index Cond: (batteryidentifier = 1177470)
Total runtime: 19275.838 ms
(18 rows)
Tim Jones
Healthcare Project Manager
Optio Software, Inc.
(770) 576-3555
-Original Message-
From: Tom Lane [mailto:[EMAIL
"Tim Jones" <[EMAIL PROTECTED]> writes:
> I have a query that uses an IN clause and it seems in perform great
> when there is more than two values in it but if there is only one it is
> really slow. Also if I change the query to use an = instead of IN in the
> case of only one value it is still s
On mið, 2006-12-13 at 13:42 -0500, Tim Jones wrote:
> I have a query that uses an IN clause and it seems in perform great
> when there is more than two values in it but if there is only one it is
> really slow. Also if I change the query to use an = instead of IN in the
> case of only one value
13 matches
Mail list logo
