Re: Planner features, discussion - Mailing list pgsql-general

From Greg Smith
Subject Re: Planner features, discussion
Date
Msg-id 4C3C7DC1.5000202@2ndquadrant.com
Whole thread Raw
In response to Planner features, discussion  (pasman pasmański <pasman.p@gmail.com>)
Responses Re: Planner features, discussion  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
pasman pasman'ski wrote:
> 1. Planner will estimate 2 x statistics: time of query with cache empty
> and with cache filled.
>

Requires planner to know something about the state of the cache; it
doesn't yet. Counting myself there's four people I know who have been
tinkering with some aspect of that enough to have written some code
related to it. For now the best you can do is lower random_page_cost
significantly when you suspect the content you're querying against is
cached.

> 2. Two levels of plannig: standard and long.
> Long planning may be used when standard optimization
> generate slow plan, and may use advanced algebraic transformations:
>

I heard a scholarly treatment of that topic from Jim Nasby recently,
where he proposed a boolean GUC to toggle the expanded search behavior
to be named plan_the_shit_out_of_it.

The surprisingly difficult part of playing in this area is getting
enough public sample data and queries running against them to be able to
do such an exercise and have some confidence you didn't decrease
performance for the average case in the process.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


pgsql-general by date:

Previous
From: Greg Smith
Date:
Subject: Re: Redundant database objects.
Next
From: Adrian Klaver
Date:
Subject: Re: Why can't I see the definition of my relations