@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
Hi,
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 slow. Possibly I need to reindex this
partic
14 matches
Mail list logo
