Clarification on the docs

On Fri, Apr 11, 2025 at 6:49 PM Igor Korot <ikorot01@gmail.com> wrote:

Hi, ALL,
On the
https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
its said:

[quote]
The optional WITH clause specifies storage parameters for the index.
Each index method has its own set of allowed storage parameters. The
B-tree, hash, GiST and SP-GiST index methods all accept this
parameter:
[/quote]

These are the index methods and the valid lists for each. The docs are
correct in how they remove duplication. I'm undecided on whether that is
the best presentation choice. I would at minimum place a new paragraph
after "own set of allowed storage parameters." so that "The B-tree,
hash..." begins its own line.

B-tree:
fillfactor
deduplicate_items

Hash:
fillfactor

Gist:
fillfactor
buffering

SP-Gist:
fillfactor

GIN:
fastupdate
gin_pending_list_limit

BRIN:
pages_per_range
autosummarize

David J.

Hi, David,

On Fri, Apr 11, 2025 at 9:04 PM David G. Johnston <
david.g.johnston@gmail.com> wrote:

On Fri, Apr 11, 2025 at 6:49 PM Igor Korot <ikorot01@gmail.com> wrote:

Hi, ALL,
On the
https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
its said:

[quote]
The optional WITH clause specifies storage parameters for the index.
Each index method has its own set of allowed storage parameters. The
B-tree, hash, GiST and SP-GiST index methods all accept this
parameter:
[/quote]

These are the index methods and the valid lists for each. The docs are
correct in how they remove duplication. I'm undecided on whether that is
the best presentation choice. I would at minimum place a new paragraph
after "own set of allowed storage parameters." so that "The B-tree,
hash..." begins its own line.

B-tree:
fillfactor
deduplicate_items

Hash:
fillfactor

Gist:
fillfactor
buffering

SP-Gist:
fillfactor

GIN:
fastupdate
gin_pending_list_limit

BRIN:
pages_per_range
autosummarize

This above looks much better. What stops you from pushing it?

There is no double meaning and everything is split nicely.

Thank you.

David J.

On Friday, April 11, 2025, Igor Korot <ikorot01@gmail.com> wrote:

Hi, David,

On Fri, Apr 11, 2025 at 9:04 PM David G. Johnston <
david.g.johnston@gmail.com> wrote:

On Fri, Apr 11, 2025 at 6:49 PM Igor Korot <ikorot01@gmail.com> wrote:

Hi, ALL,
On the https://www.postgresql.org/docs/17/sql-createindex.html#
SQL-CREATEINDEX-STORAGE-PARAMETERS
its said:

[quote]
The optional WITH clause specifies storage parameters for the index.
Each index method has its own set of allowed storage parameters. The
B-tree, hash, GiST and SP-GiST index methods all accept this
parameter:
[/quote]

These are the index methods and the valid lists for each. The docs are
correct in how they remove duplication. I'm undecided on whether that is
the best presentation choice. I would at minimum place a new paragraph
after "own set of allowed storage parameters." so that "The B-tree,
hash..." begins its own line.

This above looks much better. What stops you from pushing it?

There is no double meaning and everything is split nicely.

Because I’m undecided on what exactly would be an improvement and don’t
care enough on the basis of this single question to put effort into
figuring that out. Committers read these and if one of them wants to act
on my new paragraph suggestion great. If not, it isn’t that big a deal.
For me, this doesn’t warrant a CF entry.

David J.

"David G. Johnston" <david.g.johnston@gmail.com> writes:

Because I’m undecided on what exactly would be an improvement and don’t
care enough on the basis of this single question to put effort into
figuring that out. Committers read these and if one of them wants to act
on my new paragraph suggestion great. If not, it isn’t that big a deal.
For me, this doesn’t warrant a CF entry.

I agree this list has gotten a little messy over time, and also that
it's not a big enough deal to warrant a formal patch process.
I tried to improve matters at

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=78637a8be

regards, tom lane

Hi, Dvid,

On Fri, Apr 11, 2025, 9:04 PM David G. Johnston <david.g.johnston@gmail.com>
wrote:

On Fri, Apr 11, 2025 at 6:49 PM Igor Korot <ikorot01@gmail.com> wrote:

Hi, ALL,
On the
https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS
its said:

[quote]
The optional WITH clause specifies storage parameters for the index.
Each index method has its own set of allowed storage parameters. The
B-tree, hash, GiST and SP-GiST index methods all accept this
parameter:
[/quote]

These are the index methods and the valid lists for each. The docs are
correct in how they remove duplication. I'm undecided on whether that is
the best presentation choice. I would at minimum place a new paragraph
after "own set of allowed storage parameters." so that "The B-tree,
hash..." begins its own line.

B-tree:
fillfactor
deduplicate_items

Hash:
fillfactor

Gist:
fillfactor
buffering

SP-Gist:
fillfactor

GIN:
fastupdate
gin_pending_list_limit

BRIN:
pages_per_range
autosummarize

Could you indicate the default value for every option here?

Thank you.

On Sat, Apr 19, 2025 at 4:17 PM Igor Korot <ikorot01@gmail.com> wrote:

Could you indicate the default value for every option here?

The descriptions clearly indicate the defaults for nearly all of them, and
the one exception is a single click away (gin_pending_list_limit).

I don't find that the information is hard to understand so no, I'm not
going to spend my time summarizing it in an email.

David J.

David,

On Sat, Apr 19, 2025, 7:21 PM David G. Johnston <david.g.johnston@gmail.com>
wrote:

On Sat, Apr 19, 2025 at 4:17 PM Igor Korot <ikorot01@gmail.com> wrote:

Could you indicate the default value for every option here?

The descriptions clearly indicate the defaults for nearly all of them, and
the one exception is a single click away (gin_pending_list_limit).

I don't find that the information is hard to understand so no, I'm not
going to spend my time summarizing it in an email.

I just wanted to make it clear that if someone will put it like this in the
docs - there should be a 3 column for the default value.

Sorry for the confusion..

Thank you.