On Tue, Jul 22, 2025 at 01:15:16PM -0500, Sami Imseih wrote:
> The GUC serves multiple purposes. For example,I can create an index as
> invisible
> and use it in a controlled way, which is helpful for experimenting
> with a new index.
An in-core GUC to control the list of indexes that should be a
On Tue, Jul 22, 2025 at 06:04:50PM -0500, Sami Imseih wrote:
> Regardless of what comes out of this thread, pg_hint_plan supporting
> a NoIndexScan hint that takes in an index name, and not only a relname
> is needed. I plan on taking that up there.
Patches are welcome upstream.
--
Michael
signa
On Tue, Jul 22, 2025 at 6:50 PM David Rowley wrote:
> On Tue, 22 Jul 2025 at 05:16, Sami Imseih wrote:
> > Also, I'd like to ask. what would be the argument against offering both
> > options,
> > ALTER and a GUC to override the catalog, as currently proposed in the patch?
>
> For me, the reason
> Now wondering if it would be better to spend the effort looking at
> pg_hint_plan and seeing how hard it would be to get global hints added
> which are applied to all queries, and then add a way to disable use of
> a named index. (I don't have any experience with that extension other
> than looki
On Tue, 22 Jul 2025 at 05:16, Sami Imseih wrote:
> Also, I'd like to ask. what would be the argument against offering both
> options,
> ALTER and a GUC to override the catalog, as currently proposed in the patch?
For me, the reason I don't like ALTER TABLE + the use_invisible_index
/ force_invis
> > This is already an established pattern has been used by other
> > RDBMS's. Having worked with such interface in the past, a combo of
> > ALTER and GUC, I never thought it was awkward and it's quite simple to
> > understand/maintain. But that is subjective.
> >
>
> It's amazing what people are w
On Mon, Jul 21, 2025 at 5:24 PM Sami Imseih wrote:
>
> > > > it will still be extremely risky in
> > > > heavy production workloads. In short, we're both walking a bull
> > > > through the china shop, but it would seem mine is much more
> > > > temperamental than yours.
> > >
> > > Robert, Could y
> > > it will still be extremely risky in
> > > heavy production workloads. In short, we're both walking a bull
> > > through the china shop, but it would seem mine is much more
> > > temperamental than yours.
> >
> > Robert, Could you describe the GUC you would like to see?
> >
> > Also, I'd like
On Mon, Jul 21, 2025 at 1:17 PM Sami Imseih wrote:
>
> > it will still be extremely risky in
> > heavy production workloads. In short, we're both walking a bull
> > through the china shop, but it would seem mine is much more
> > temperamental than yours.
>
> Robert, Could you describe the GUC you
> it will still be extremely risky in
> heavy production workloads. In short, we're both walking a bull
> through the china shop, but it would seem mine is much more
> temperamental than yours.
Robert, Could you describe the GUC you would like to see?
Also, I'd like to ask. what would be the argu
On Thu, Jul 17, 2025 at 9:49 PM David Rowley wrote:
>
> On Wed, 16 Jul 2025 at 05:59, Robert Treat wrote:
> > operational risk within the system. Similarly, the nature of the DDL
> > change also requires that all sessions be impacted everywhere at once;
> > there is no way to slowly roll the chan
On Fri, 18 Jul 2025 at 14:25, Sami Imseih wrote:
> I’d argue we should not provide the ALTER option without the GUC, for
> more granular control.
If you mean the use_invisible_index GUC, then for transparency here,
I'm not in favour of that. I do understand that this might be useful
when trying t
> My concern with #1 is that when we one day do get query hints, we'll
> be left with a bunch of redundant ways to influence planner behaviour.
The GUC is more than just a hint. It can serve as a hint, but it also offers
operational benefits. For example, if I mark an index as invisible and that
On Wed, 16 Jul 2025 at 05:59, Robert Treat wrote:
> operational risk within the system. Similarly, the nature of the DDL
> change also requires that all sessions be impacted everywhere at once;
> there is no way to slowly roll the change to some segment of the
> database or some specific workload
On Tue, Jul 15, 2025 at 8:19 AM Shayon Mukherjee wrote:
> On Jun 23, 2025, at 10:14 AM, Robert Treat wrote:
> Glad to hear you are still interested, slightly disheartened by the
> general lack of concern around operational safety in this thread. I
> actually think what you have done covers a lot
> On Jun 23, 2025, at 10:14 AM, Robert Treat wrote:
>>
Sorry for the late response, been busy at work :D.
>
> Glad to hear you are still interested, slightly disheartened by the
> general lack of concern around operational safety in this thread. I
> actually think what you have done covers
On Sat, Jun 21, 2025 at 7:37 AM Shayon Mukherjee wrote:
> On Jun 11, 2025, at 9:00 AM, Sami Imseih wrote:
>> IMO, having this GUC to force the use of invisible indexes is quite
>> strange. In my view, it detracts from the guarantees that you're meant
>> to get from disabling indexes. What if some
On Sat, Jun 21, 2025 at 10:59 AM Merlin Moncure wrote:
> On Sat, Jun 21, 2025 at 8:38 AM Shayon Mukherjee wrote:
>> The primary use case I have in mind is for helping engineers (ones not so
>> seasoned like DBAs) decide whether to drop *existing* indexes. For new
>> indexes, I expect most users
Hi Shayon,
On Sat, Jun 21, 2025 at 9:38 PM Shayon Mukherjee wrote:
>
>
>
> On Jun 11, 2025, at 9:00 AM, Sami Imseih wrote:
>
>
>> IMO, having this GUC to force the use of invisible indexes is quite
>> strange. In my view, it detracts from the guarantees that you're meant
>> to get from disabling
> On Jun 11, 2025, at 9:00 AM, Sami Imseih wrote:
>
>
>> IMO, having this GUC to force the use of invisible indexes is quite
>> strange. In my view, it detracts from the guarantees that you're meant
>> to get from disabling indexes. What if some connection has
>> use_invisible_index set to tru
On Sat, Jun 21, 2025 at 8:38 AM Shayon Mukherjee wrote:
>
>
> On Jun 11, 2025, at 9:00 AM, Sami Imseih wrote:
>
>
> IMO, having this GUC to force the use of invisible indexes is quite
>> strange. In my view, it detracts from the guarantees that you're meant
>> to get from disabling indexes. What
Hi David,
Thank you so much for the review and pointers. I totally missed expression
indexes. I am going to do another proper pass along with your feedback and
follow up with an updated patch and any questions.
Excited to be learning so much about the internals.
Shayon
> On Sep 22, 2024, at
22 matches
Mail list logo
