From: Cédric Villemain <cedric.villemain.debian@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Vlad Arkhipov <arhipov@dc.baikal.ru>
Cc: pgsql-performance@postgresql.org
Subject: Re: Optimization idea
Date: Sat, 1 May 2010 14:00:32 +0200
Message-ID: <q2te94e14cd1005010500z89932bd8p29a9fb37fe64c57@mail.gmail.com> (raw)
In-Reply-To: <w2he94e14cd1005010352xc91e4e72t298db4cdecb5bc59@mail.gmail.com>
References: <4BD0161A.4010908@dc.baikal.ru>
<4BD0430C.1050308@2ndquadrant.com>
<4BD10805.9060004@dc.baikal.ru>
<y2y603c8f071004230405r5fcef546l3da84c407ce2655a@mail.gmail.com>
<4BD4FFE7.9090305@dc.baikal.ru>
<x2te94e14cd1004260233i45c44966qc4a8b10f4edb2963@mail.gmail.com>
<q2w603c8f071004271746s43f8669cz45bec5914b1fa9e0@mail.gmail.com>
<w2he94e14cd1005010352xc91e4e72t298db4cdecb5bc59@mail.gmail.com>
2010/5/1 Cédric Villemain <cedric.villemain.debian@gmail.com>:
> 2010/4/28 Robert Haas <robertmhaas@gmail.com>:
>> On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
>> <cedric.villemain.debian@gmail.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 :
> http://archives.postgresql.org/pgsql-general/2010-05/msg00009.php ?
not, sorry ,misread about prepared statement in the other thread ...
>
>>
>> ...Robert
>>
>
>
>
> --
> Cédric Villemain
>
--
Cédric Villemain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cedric.villemain.debian@gmail.com, robertmhaas@gmail.com, arhipov@dc.baikal.ru
Subject: Re: Optimization idea
In-Reply-To: <q2te94e14cd1005010500z89932bd8p29a9fb37fe64c57@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox