2011/1/18 masterchief
>
> > 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 sc
> 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
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 (pgsql-per
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? &#x
2010/12/8 Tom Lane :
> Shrirang Chitnis 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
>>
@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 (not
Shrirang Chitnis 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 collection_data
>
ithin 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 tha
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 c
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
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
11 matches
Mail list logo
