Skip site navigation (1) Skip section navigation (2)

Re: Optimization idea

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimization idea
Date: 2010-05-01 12:00:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
2010/5/1 Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>:
> 2010/4/28 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
>> <cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
>>> In the first query, the planner doesn't use the information of the 2,3,4.
>>> It just does a : I'll bet I'll have 2 rows in t1 (I think it should
>>> say 3, but it doesn't)
>>> So it divide the estimated number of rows in the t2 table by 5
>>> (different values) and multiply by 2 (rows) : 40040.
>> I think it's doing something more complicated.  See scalararraysel().
>>> In the second query the planner use a different behavior : it did
>>> expand the value of t1.t to t2.t for each join relation and find a
>>> costless plan. (than the one using seqscan on t2)
>> I think the problem here is one we've discussed before: if the query
>> planner knows that something is true of x (like, say, x =
>> ANY('{2,3,4}')) and it also knows that x = y, it doesn't infer that
>> the same thing holds of y (i.e. y = ANY('{2,3,4}') unless the thing
>> that is known to be true of x is that x is equal to some constant.
>> Tom doesn't think it would be worth the additional CPU time that it
>> would take to make these sorts of deductions.  I'm not sure I believe
>> that, but I haven't tried to write the code, either.
> Relative to this too :
>  ?

not, sorry ,misread about prepared statement in the other thread ...

>> ...Robert
> --
> Cédric Villemain

Cédric Villemain

In response to

pgsql-performance by date

Next:From: Scott MarloweDate: 2010-05-01 16:08:36
Subject: Re: autovacuum strategy / parameters
Previous:From: Robert HaasDate: 2010-05-01 11:39:09
Subject: Re: autovacuum strategy / parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group