Re: doc: BRIN indexes and autosummarize

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Roberto Mello <roberto(dot)mello(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: doc: BRIN indexes and autosummarize
Date: 2022-07-04 15:20:11
Message-ID: 20220704152011.4rypgtgfu66rktkq@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2022-Jun-28, Roberto Mello wrote:

> Here's a patch to clarify the BRIN indexes documentation, particularly with
> regards to autosummarize, vacuum and autovacuum. It basically breaks
> down a big blob of a paragraph into multiple paragraphs for clarity,
> plus explicitly tells how summarization happens manually or
> automatically.

[Some of] these additions are wrong actually. It says that autovacuum
will not summarize new entries; but it does. If you just let the table
sit idle, any autovacuum run that cleans the table will also summarize
any ranges that need summarization.

What 'autosummarization=off' means is that the behavior to trigger an
immediate summarization of a range once it becomes full is not default.
This is very different.

As for the new <para></para>s that you added, I'd say they're
stylistically wrong. Each paragraph is supposed to be one fully
contained idea; what these tags do is split each idea across several
smaller paragraphs. This is likely subjective though.

> On this topic... I'm not familiar with with the internals of BRIN
> indexes and in backend/access/common/reloptions.c I see:
>
> {
> "autosummarize",
> "Enables automatic summarization on this BRIN index",
> RELOPT_KIND_BRIN,
> AccessExclusiveLock
> },
>
> Is the exclusive lock on the index why autosummarize is off by default?

No. The lock level mentioned here is what needs to be taken in order to
change the value of this option.

> What would be the downside (if any) of having autosummarize=on by default?

I'm not aware of any. Maybe we should turn it on by default.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2022-07-04 16:29:13 Re: Add connection active, idle time to pg_stat_activity
Previous Message Tom Lane 2022-07-04 14:39:37 Re: TAP output format in pg_regress