From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Planner not using column limit specified for one column for another column equal to first |
Date: | 2010-04-17 04:12:18 |
Message-ID: | n2o331e40661004162112u52e89c27i77dbade091133df4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
16 квітня 2010 р. 17:19 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написав:
> =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= <tivv00(at)gmail(dot)com> writes:
> > I've thought and someone in this list've told me that this should be done
> > automatically.
>
> As was pointed out, even if we had such logic it wouldn't apply in this
> example, because the equality conditions aren't real equalities but
> OUTER JOIN conditions.
>
>
In this case you can copy condition to "ON" condition, not to where cause
and this would work correct, e.g. "select something from a join b on a.x=b.y
where a.x > n" <=> "select something from a join b on a.x=b.y and b.y > n
where a.x > n".
As of making planner more clever, may be it is possible to introduce
division on "fast queries" and "long queries", so that if after fast
planning cost is greater then some configurable threshold, advanced planning
techniques (or settings) are used. As far as I have seen in this list, many
techniques are not used simply because they are too complex and could make
planning take too much time for really fast queries, but they are vital for
long ones.
Also same (or similar) threshold could be used to enable replanning for each
run of prepared query - also an often complaint is that planned query is not
that fast as is could be.
--
Best regards,
Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2010-04-19 09:47:37 | Re: Planner not using column limit specified for one column for another column equal to first |
Previous Message | Josh Kupershmidt | 2010-04-16 19:40:51 | Re: stats collector suddenly causing lots of IO |