Tom Lane wrote:
The only really effective way the planner knows to optimize an
IN (sub-SELECT) is to turn it into a semi-join, which is not possible
here because of the unrelated OR clause. You might consider replacing
this with a UNION of two scans of contexts. (And yes, I know it'd be
2011/1/18 masterchief esi...@theiqgroup.com
Tom Lane wrote:
The only really effective way the planner knows to optimize an
IN (sub-SELECT) is to turn it into a semi-join, which is not possible
here because of the unrelated OR clause. You might consider replacing
this with a UNION of
Can you help me understand how to optimize the following. There's a
subplan which in this case returns 3 rows,
but it is really expensive:
=
explain analyze SELECT contexts.context_key
FROM contexts
JOIN articles
of the original message.
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Bryce Nesbitt
Sent: Thursday, December 09, 2010 12:24 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] hashed subplan 5000x slower than
Shrirang Chitnis wrote:
Bryce,
The two queries are different:
Ah, due to a mistake. The first version with the hashed subplan is from
production.
The second version should have read:
production= SELECT
the given transaction.
regards,
Marc Mamin
-Ursprüngliche Nachricht-
Von: pgsql-performance-ow...@postgresql.org im Auftrag von Shrirang Chitnis
Gesendet: Mi 12/8/2010 8:05
An: Bryce Nesbitt; pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] hashed subplan 5000x slower than two
Shrirang Chitnis shrirang.chit...@hovservices.com writes:
Bryce,
The two queries are different:
I suspect the second one is a typo and not what he really wanted.
WHERE (contexts.parent_key = 392210
OR contexts.context_key IN
(SELECT collection_data.context_key
FROM
@postgresql.org
Betreff: Re: [PERFORM] hashed subplan 5000x slower than two sequential
operations
Hello,
are the table freshly analyzed, with a sufficient default_statistics_target ?
You may try to get a better plan while rewriting the query as an UNION to get
rid of the OR clause.
Something like
2010/12/8 Tom Lane t...@sss.pgh.pa.us:
Shrirang Chitnis shrirang.chit...@hovservices.com writes:
Bryce,
The two queries are different:
I suspect the second one is a typo and not what he really wanted.
WHERE (contexts.parent_key = 392210
OR contexts.context_key IN
(SELECT
Title: AW: [PERFORM] hashed subplan 5000x slower than two sequential
operations
Marc Mamin wrote:
Hello,
are the table freshly analyzed, with a sufficient
default_statistics_target ?
autovacuum = on # Enable autovacuum
subprocess? 'on'
autovacuum_naptime = 5min # time
Marc Mamin wrote:
Another point: would a conditionl index help ?
on articles (context_key) where indexed
no.
production= select count(*),indexed from articles group by indexed;
count | indexed
+-
517433 | t
695814 | f
--
Sent via pgsql-performance mailing list
11 matches
Mail list logo
