Re: Planner hints in Postgresql - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Planner hints in Postgresql
Date
Msg-id CAGTBQpZ13kbHV3mJppvk0wEJyfUDPSOKhJEG7iaSgYQVnT7xig@mail.gmail.com
Whole thread
In response to Re: Planner hints in Postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Planner hints in Postgresql
Re: Planner hints in Postgresql
List pgsql-hackers

On Mon, Mar 17, 2014 at 8:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Claudio Freire <klaussfreire@gmail.com> writes:
> On Mon, Mar 17, 2014 at 7:01 PM, Jim Nasby <jim@nasby.net> wrote:
>> Even better would be if the planner could estimate how bad a plan will
>> become if we made assumptions that turn out to be wrong.

> That's precisely what risk estimation was about.

Yeah.  I would like to see the planner's cost estimates extended to
include some sort of uncertainty estimate, whereupon risk-averse people
could ask it to prefer low-uncertainty plans over high-uncertainty ones
(the plans we typically choose for ORDER BY ... LIMIT queries being great
examples of the latter).  But it's a long way from wishing that to making
it so.  Right now it's not even clear (to me anyway) how we'd measure or
model such uncertainty.

Well, currently, selectivity estimates based on MCV should be pretty low-uncertainty, whereas certainty of other estimates could be modeled as a random variable if ANALYZE gathered a few statistical moments (for variables that are prone to that kind of statistical analysis).

That alone could improve things considerably, and statistical info could be propagated along expressions to make it possible to model uncertainty in complex expressions as well.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Next
From: Greg Stark
Date:
Subject: json/jsonb/hstore operator precedence