Re: On disable_cost

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: On disable_cost
Date: 2024-10-18 10:54:49
Message-ID: CAApHDvrVJX23R48NiEZxebM8+0S8LzhnBU5=AZ2Ar=59F75+kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 12 Oct 2024 at 02:16, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Fri, 2024-10-11 at 20:45 +1300, David Rowley wrote:
> > + When using the enable/disable flags to disable plan node types, the
> > + majority of the flags only deprioritize the corresponding plan node
>
> I don't like "deprioritize".
> How about "discourage the use of"?

Yeah, that's ok for me.

> Besides, is that really the majority? I had though that only a few nodes
> are unavoidable (sequential scan, sort, nested loop). But I guess I am wrong.

Ok, I looked and you're right. I did make a quick pass to
approximately figure that out and I came up with:

Soft disable: enable_bitmapscan, enable_gathermerge, enable_hashagg,
enable_hashjoin, enable_indexscan, enable_mergejoin, enable_nestloop,
enable_seqscan, enable_sort

That's 9.

Hard disable: enable_async_append, enable_group_by_reordering,
enable_incremental_sort, enable_indexonlyscan, enable_material,
enable_memoize, enable_parallel_append, enable_parallel_hash,
enable_partition_pruning, enable_partitionwise_aggregate,
enable_partitionwise_join, enable_presorted_aggregate, enable_tidscan

And 13.

(there are a few ones that are in a grey area such as enable_hashagg
or enable_tidscan will still happen with a WHERE CURRENT OF <cursor>.)

I changed "majority" to "many"

> > + and don't outright disallow the planner's ability to use the plan node
> > + type. This is done so that the planner still maintains the ability to
> > + form a plan for a given query. Otherwise, certain queries would not be
> > + possible to execute when certain plan node types are disabled. This means
>
> "would not be possible to execute" can be simplified to "could be executed".

Changed.

> Can we have "sequential scan" instead of "Seq Scan"?
> It's somewhat unrelated, but I cannot count how many people I have talked
> to who think that it is a "sequence scan".

Yeah, looks like we only call it "Seq Scan" in EXPLAIN and we use
"sequence scan" when talking about it in sentences.

Thanks for looking. Updated patch is attached.

David

Attachment Content-Type Size
disabled_docs_v2.patch application/octet-stream 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-10-18 10:55:33 Re: DOCS - pg_replication_slot . Fix the 'inactive_since' description
Previous Message Peter Eisentraut 2024-10-18 10:11:00 unicode test programs don't build with meson