From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: suggest to rename enable_incrementalsort |
Date: | 2020-06-21 23:18:24 |
Message-ID: | CAApHDvrbM7rmBo0am6pM+BkwRQWdOuHtpSWHrk=SS7KnXN1P7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 21 Jun 2020 at 23:22, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On Sun, Jun 21, 2020 at 09:05:32AM +0200, Julien Rouhaud wrote:
> >On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut
> ><peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> >>
> >> I suggest to rename enable_incrementalsort to enable_incremental_sort.
> >> This is obviously more readable and also how we have named recently
> >> added multiword planner parameters.
> >>
> >> See attached patch.
> >
> >+1, this is a way better name (and patch LGTM on REL_13_STABLE).
> >
>
> The reason why I kept the single-word variant is consistency with other
> GUCs that affect planning, like enable_indexscan, enable_hashjoin and
> many others.
Looking at the other enable_* GUCs, for all the ones that aim to
disable a certain executor node type, with the exception of
enable_hashagg and enable_bitmapscan, they're all pretty consistent in
naming the GUC after the executor node's .c file:
enable_bitmapscan nodeBitmapHeapscan.c
enable_gathermerge nodeGatherMerge.c
enable_hashagg nodeAgg.c
enable_hashjoin nodeHashjoin.c
enable_incrementalsort nodeIncrementalSort.c
enable_indexonlyscan nodeIndexonlyscan.c
enable_indexscan nodeIndexscan.c
enable_material nodeMaterial.c
enable_mergejoin nodeMergejoin.c
enable_nestloop nodeNestloop.c
enable_parallel_append nodeAppend.c
enable_parallel_hash nodeHash.c
enable_partition_pruning
enable_partitionwise_aggregate
enable_partitionwise_join
enable_seqscan nodeSeqscan.c
enable_sort nodeSort.c
enable_tidscan nodeTidscan.c
enable_partition_pruning, enable_partitionwise_aggregate,
enable_partitionwise_join are the odd ones out here as they're not
really related to a specific node type.
Going by that, it does seem the current name for
enable_incrementalsort is consistent with the majority. Naming it
enable_incremental_sort looks like it would be more suited if the
feature had been added by overloading nodeSort.c. In that regard, it
would be similar to enable_parallel_append and enable_parallel_hash,
where the middle word becomes a modifier.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2020-06-22 00:14:39 | Re: new heapcheck contrib module |
Previous Message | David Rowley | 2020-06-21 22:52:04 | Re: Parallel Seq Scan vs kernel read ahead |