Re: Planner not using column limit specified for one column for another column equal to first

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.

In response to

Browse pgsql-performance by date

  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