I have a join that uses three tables but it runs rather slow. For
example, the following command takes about 10 min. to run. It gets the
correct result but what should I do to increase the performance of this
query? This query is the end result of some python code hence the big
id list.
my
Here is the query plan:
QUERYPLAN
Gerry Reno wrote:
I have a join that uses three tables but it runs rather slow. For
example, the following command takes about 10 min. to run. It gets the
correct result but what should I do to increase the performance of this
query? This query is the end result of some python code hence the
Ok, I've been playing around with this SQL some more and I found that if
I remove this:
e.active = '1'
from the query that the query now completes in 5 seconds. Nothing else
has anywhere near the impact of this boolean condition. So what is it
about this boolean field that is causing so much
On 11/12/2007, Gerry Reno <[EMAIL PROTECTED]> wrote:
> Ok, I've been playing around with this SQL some more and I found that if
> I remove this:
> e.active = '1'
> from the query that the query now completes in 5 seconds. Nothing else
> has anywhere near the impact of this boolean condition. So w
Pavel Stehule wrote:
On 11/12/2007, Gerry Reno <[EMAIL PROTECTED]> wrote:
Ok, I've been playing around with this SQL some more and I found that if
I remove this:
e.active = '1'
from the query that the query now completes in 5 seconds. Nothing else
has anywhere near the impact of this boolean
Hello
there is diference in agg position. Send, please, query and explain
analyze output. And test id = any (... ) looks like hard
denormalisation and can do problems. This condition can be slow and
for large arrays is better use multivalues.
SELECT *
FROM tab
WHERE x IN (VALUES(10),(20));
Pavel Stehule wrote:
Hello
there is diference in agg position. Send, please, query and explain
analyze output. And test id = any (... ) looks like hard
denormalisation and can do problems. This condition can be slow and
for large arrays is better use multivalues.
SELECT *
FROM tab
WHERE x
Hello
1) increase statistics on res_partner_address.type (about 100)
alter table ...
ALTER [ COLUMN ] column SET STATISTICS integer
do analyze, and look again on plans. There are difference
-> Seq Scan on res_partner_address a (cost=0.00..88.40
rows=16 width=552) (actual time=0.106..3.
Gerry Reno <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> there is diference in agg position. Send, please, query and explain
>> analyze output.
[ explain analyze output ]
The rowcount estimates seem pretty far off, even for simple cases that
I'd expect it to get right, eg
> ->
Tom Lane wrote:
Gerry Reno <[EMAIL PROTECTED]> writes:
Pavel Stehule wrote:
there is diference in agg position. Send, please, query and explain
analyze output.
[ explain analyze output ]
The rowcount estimates seem pretty far off, even for simple cases that
I'd expect it to ge
11 matches
Mail list logo
