From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Jose Luis Tallon <jltallon(at)adv-solutions(dot)net> |
Subject: | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |
Date: | 2020-09-02 04:56:44 |
Message-ID: | 20200902045644.GC20149@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 01, 2020 at 09:24:10PM -0500, Justin Pryzby wrote:
> On Wed, Sep 02, 2020 at 10:00:12AM +0900, Michael Paquier wrote:
> > On Tue, Sep 01, 2020 at 11:48:30AM -0400, Alvaro Herrera wrote:
> > > On 2020-Sep-01, Justin Pryzby wrote:
> > >> The question isn't whether to use a parenthesized option list. I realized that
> > >> long ago (even though Alexey didn't initially like it). Check 0002, which gets
> > >> rid of "bool concurrent" in favour of stmt->options&REINDEXOPT_CONCURRENT.
> > >
> > > Ah! I see, sorry for the noise. Well, respectfully, having a separate
> > > boolean to store one option when you already have a bitmask for options
> > > is silly.
> >
> > Yeah, I am all for removing "concurrent" from ReindexStmt, but I don't
> > think that the proposed 0002 is that, because it is based on the
> > assumption that we'd want more than just boolean-based options in
> > those statements, and this case is not justified yet except if it
> > becomes possible to enforce tablespaces. At this stage, I think that
> > it is more sensible to just update gram.y and add a
> > REINDEXOPT_CONCURRENTLY. I also think that it would also make sense
> > to pass down "options" within ReindexIndexCallbackState() (for example
> > imagine a SKIP_LOCKED for REINDEX).
>
> Uh, this whole thread is about implementing REINDEX (TABLESPACE foo), and the
> preliminary patch 0001 is to keep separate the tablespace parts of that
> content. 0002 is a minor tangent which I assume would be squished into 0001
> which cleans up historic cruft, using new params in favour of historic options.
>
> I think my change is probably incomplete, and ReindexStmt node should not have
> an int options. parse_reindex_params() would parse it into local int *options
> and char **tablespacename params.
Done in the attached, which is also rebased on 1d6541666.
And added RelationAssumeNewRelfilenode() as I mentioned - but I'm hoping to
hear from Michael about any reason not to call RelationSetNewRelfilenode()
instead of directly calling the things it would itself call.
--
Justin
Attachment | Content-Type | Size |
---|---|---|
v23-0001-Change-REINDEX-CLUSTER-to-accept-an-option-list.patch | text/x-diff | 23.6 KB |
v23-0002-Deprecate-ReindexStmt-concurrent-and-options.patch | text/x-diff | 16.4 KB |
v23-0003-Allow-REINDEX-to-change-tablespace.patch | text/x-diff | 29.6 KB |
v23-0004-Allow-CLUSTER-and-VACUUM-FULL-to-change-tablespa.patch | text/x-diff | 23.6 KB |
v23-0005-Implement-vacuum-full-cluster-INDEX_TABLESPACE-t.patch | text/x-diff | 19.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2020-09-02 05:05:23 | describe-config issue |
Previous Message | Hao Wu | 2020-09-02 04:25:16 | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |