Re: allowing extensions to control planner behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allowing extensions to control planner behavior
Date
Msg-id 3118814.1724783090@sss.pgh.pa.us
Whole thread Raw
In response to Re: allowing extensions to control planner behavior  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: allowing extensions to control planner behavior
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, now I'm confused. Just yesterday, in response to the 0001 patch
> that allows extensions to exert control over the join strategy, you
> complained that "Or, if your problem is that the planner wants to scan
> index A but you want it to scan index B, enable_indexscan won't help."

I was just using that to illustrate that making the enable_XXX GUCs
relation-local covers only a small part of the planner-control problem.
You had not, at that point, been very clear that you intended that
patch as only a small part of a solution.

I do think that index selection is pretty well under control already,
thanks to stuff that we put in ages ago at the urging of people who
wanted to write "index advisor" extensions.  (The fact that that
area seems a bit moribund is disheartening, though.  Is it a lack
of documentation?)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)
Next
From: Andres Freund
Date:
Subject: Re: remove adaptive spins_per_delay code