From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
---|---|
To: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-19 09:47:37 |
Message-ID: | alpine.DEB.2.00.1004191043280.27544@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, 17 Apr 2010, Віталій Тимчишин wrote:
> 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.
+1. That's definitely a good idea in my view. The query optimiser I wrote
(which sits on top of Postgres and makes use of materialised views to
speed up queries) uses a similar approach - it expends effort proportional
to the estimated cost of the query, as reported by EXPLAIN.
Matthew
--
To most people, solutions mean finding the answers. But to chemists,
solutions are things that are still all mixed up.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Carey | 2010-04-19 18:05:59 | Re: Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set |
Previous Message | Віталій Тимчишин | 2010-04-17 04:12:18 | Re: Planner not using column limit specified for one column for another column equal to first |