DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	b=vGdhnMpvdSLyQrT+oL+MSMUuaR2QciE/XHn2GUkTQNUFayM82NI7mjexnDL7JOSghV
	PD/Fevg6MLOK78PNcGk0OediCiMyfMMoR4njFHjfrnm3QXT7GYPeL8FAQMMA8y6jEZAU
	DWwAiD7Sz+qs5DIK4YtBnVFmL4YKJK7ca4dXk=
MIME-Version: 1.0
In-Reply-To: <q2w603c8f071004271746s43f8669cz45bec5914b1fa9e0@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>
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric.villemain.debian@gmail.com>
Date: Sat, 1 May 2010 12:52:35 +0200
Message-ID: <w2he94e14cd1005010352xc91e4e72t298db4cdecb5bc59@mail.gmail.com>
Subject: Re: Optimization idea
To: Robert Haas <robertmhaas@gmail.com>
Cc: Vlad Arkhipov <arhipov@dc.baikal.ru>, pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2010/4/28 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Apr 26, 2010 at 5:33 AM, C=E9dric 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. =A0See 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 =3D
> ANY('{2,3,4}')) and it also knows that x =3D y, it doesn't infer that
> the same thing holds of y (i.e. y =3D 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. =A0I'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  ?

>
> ...Robert
>


--=20
C=E9dric Villemain