agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Steve Singer <steve@ssinger.info>
Cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Jose Luis Tallon <jltallon@adv-solutions.net>
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Date: Tue, 15 Dec 2020 13:34:35 +0300
Message-ID: <d177d8148f67bd8f6bad5fb0473879be@postgrespro.ru> (raw)
In-Reply-To: <20201215001417.GC30237@telsasoft.com>
References: <20201211202703.GA21264@alvherre.pgsql>
<7ec67c56-2377-cd05-51a0-691104404abe@enterprisedb.com>
<20201212194526.GE24052@telsasoft.com>
<20201215001417.GC30237@telsasoft.com>
On 2020-12-15 03:14, Justin Pryzby wrote:
> On Sat, Dec 12, 2020 at 01:45:26PM -0600, Justin Pryzby wrote:
>> On Sat, Dec 12, 2020 at 09:20:35AM +0100, Peter Eisentraut wrote:
>> > On 2020-12-11 21:27, Alvaro Herrera wrote:
>> > > By the way-- What did you think of the idea of explictly marking the
>> > > types used for bitmasks using types bits32 and friends, instead of plain
>> > > int, which is harder to spot?
>> >
>> > If we want to make it clearer, why not turn the thing into a struct, as in
>> > the attached patch, and avoid the bit fiddling altogether.
>>
>> I like this.
>> It's a lot like what I wrote as [PATCH v31 1/5] ExecReindex and
>> ReindexParams
>> In my v31 patch, I moved ReindexOptions to a private structure in
>> indexcmds.c,
>> with an "int options" bitmask which is passed to reindex_index() et
>> al. Your
>> patch keeps/puts ReindexOptions index.h, so it also applies to
>> reindex_index,
>> which I think is good.
>>
>> So I've rebased this branch on your patch.
>>
>> Some thoughts:
>>
>> - what about removing the REINDEXOPT_* prefix ?
>> - You created local vars with initialization like "={}". But I
>> thought it's
>> needed to include at least one struct member like "={false}", or
>> else
>> they're not guaranteed to be zerod ?
>> - You passed the structure across function calls. The usual
>> convention is to
>> pass a pointer.
>
> I think maybe Michael missed this message (?)
> I had applied some changes on top of Peter's patch.
>
> I squished those commits now, and also handled ClusterOption and
> VacuumOption
> in the same style.
>
> Some more thoughts:
> - should the structures be named in plural ? "ReindexOptions" etc.
> Since they
> define *all* the options, not just a single bit.
> - For vacuum, do we even need a separate structure, or should the
> members be
> directly within VacuumParams ? It's a bit odd to write
> params.options.verbose. Especially since there's also ternary
> options which
> are directly within params.
This is exactly what I have thought after looking on Peter's patch.
Writing 'params.options.some_option' looks just too verbose. I even
started moving all vacuum options into VacuumParams on my own and was in
the middle of the process when realized that there are some places that
do not fit well, like:
if (!vacuum_is_relation_owner(RelationGetRelid(onerel),
onerel->rd_rel,
params->options & VACOPT_ANALYZE))
Here we do not want to set option permanently, but rather to trigger
some additional code path in the vacuum_is_relation_owner(), IIUC. With
unified VacuumParams we should do:
bool opt_analyze = params->analyze;
...
params->analyze = true;
if (!vacuum_is_relation_owner(RelationGetRelid(onerel),
onerel->rd_rel, params))
...
params->analyze = opt_analyze;
to achieve the same, but it does not look good to me, or change the
whole interface. I have found at least one other place like that so far
--- vacuum_open_relation() in the analyze_rel().
Not sure how we could better cope with such logic.
> - Then, for cluster, I think it should be called ClusterParams, and
> eventually
> include the tablespaceOid, like what we're doing for Reindex.
>
> I am awaiting feedback on these before going further since I've done
> too much
> rebasing with these ideas going back and forth and back.
Yes, we have moved a bit from my original patch set in the thread with
all this refactoring. However, all the consequent patches are heavily
depend on this interface, so let us decide first on the proposed
refactoring.
Regards
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
view thread (154+ messages) latest in thread
Message-ID: <d177d8148f67bd8f6bad5fb0473879be@postgrespro.ru>
Permalink: ../d177d8148f67bd8f6bad5fb0473879be@postgrespro.ru/
Also on: postgresql.org/message-id/d177d8148f67bd8f6bad5fb0473879be@postgrespro.ru
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.kondratov@postgrespro.ru, pryzby@telsasoft.com, peter.eisentraut@enterprisedb.com, alvherre@alvh.no-ip.org, michael@paquier.xyz, masahiko.sawada@2ndquadrant.com, steve@ssinger.info, robertmhaas@gmail.com, a.korotkov@postgrespro.ru, sawada.mshk@gmail.com, jltallon@adv-solutions.net
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
In-Reply-To: <d177d8148f67bd8f6bad5fb0473879be@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox