Re: allowing extensions to control planner behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing extensions to control planner behavior
Date: 2024-08-27 18:24:50
Message-ID: 3118814.1724783090@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-08-27 18:27:00 Re: remove adaptive spins_per_delay code
Previous Message Dmitry Koval 2024-08-27 18:24:35 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands