Horton

Thread

Commits

  1. Doc: do a little copy-editing on Index Storage Parameters list.

  1. Re: Clarification on the docs

    David G. Johnston <david.g.johnston@gmail.com> — 2025-04-12T02:03:38Z

    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.

  2. Re: Clarification on the docs

    Igor Korot <ikorot01@gmail.com> — 2025-04-12T03:08:48Z

    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.
>
>

  3. Re: Clarification on the docs

    David G. Johnston <david.g.johnston@gmail.com> — 2025-04-12T03:22:03Z

    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.

  4. Clarification on the docs

    Igor Korot <ikorot01@gmail.com> — 2025-04-12T06:09:50Z

    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]

It states that each index method has its own set.

However only 3 out of predefined are given.

Moore over after that quote there is a list of parameters. But the
last phrase indicates a single parameter.

So how should I read that?

Is it a typo and it has to be plural, oor the list needs to be
ybindented and only one parameter should be there?

Thank you.

  5. Re: Clarification on the docs

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-04-12T17:44:44Z

    "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

  6. Re: Clarification on the docs

    Igor Korot <ikorot01@gmail.com> — 2025-04-19T23:16:53Z

    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.


> David J.
>
>

  7. Re: Clarification on the docs

    David G. Johnston <david.g.johnston@gmail.com> — 2025-04-20T00:20:58Z

    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.

  8. Re: Clarification on the docs

    Igor Korot <ikorot01@gmail.com> — 2025-04-20T00:32:41Z

    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.


> David J.
>
>