On Thu, Jan 31, 2019 at 03:41:34PM +, Bossart, Nathan wrote:
> Thanks for the diligent reviews, as always. I don't plan to pick up
> --min-relation-size right now, but I may attempt it again in a future
> commitfest.
Sure, thanks for the patches!
--
Michael
signature.asc
Description: PGP si
On 1/30/19, 8:21 PM, "Michael Paquier" wrote:
> Fixed and committed. So we are finally done here, except for the
> debate with the relation size.
Thanks for the diligent reviews, as always. I don't plan to pick up
--min-relation-size right now, but I may attempt it again in a future
commitfest.
On Thu, Jan 31, 2019 at 02:28:05AM +, Bossart, Nathan wrote:
> It looks good to me. The only thing I noticed is the use of
> relfrozenxid instead of relminmxid here:
Fixed and committed. So we are finally done here, except for the
debate with the relation size.
--
Michael
signature.asc
Des
On 1/30/19, 6:04 PM, "Michael Paquier" wrote:
> Something which was not correct in the patch is the compatibility of
> the query. xid <> xid has been added in 9.6, so the new options will
> not be able to work with older versions. The versions marked as
> compatible in the last patch came from t
On Wed, Jan 30, 2019 at 05:45:58PM +, Bossart, Nathan wrote:
> On 1/29/19, 4:47 PM, "Michael Paquier" wrote:
>> Oh, OK. This makes sense. It would be nice to add a comment in the
>> patch and to document this calculation method in the docs of
>> vacuumdb.
>
> Sure, this is added in v8.
Tha
On Tue, Jan 29, 2019 at 09:48:18PM +, Bossart, Nathan wrote:
> On 1/28/19, 6:35 PM, "Michael Paquier" wrote:
>> -" ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n");
>> +" ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n"
>> +" LEFT JOIN pg_catalog.pg_class t"
>> +" ON c.rel
On Mon, Jan 28, 2019 at 09:58:17PM +, Bossart, Nathan wrote:
> Yes, this simplifies the code quite a bit. I did it this way in
> v6.
Thanks for the quick update. Things could have been made a bit more
simple by just using a for loop instead of while, even if the table
list can be NULL for da
On Thu, Jan 24, 2019 at 12:49:28AM +, Bossart, Nathan wrote:
> Oh, wow. Thanks for pointing this out. I should have caught this.
> With 0002, we are basically just throwing out the column lists
> entirely as we obtain the qualified identifiers from the catalog
> query. To fix this, I've adde
On Thu, Jan 24, 2019 at 12:49:28AM +, Bossart, Nathan wrote:
> Oh, wow. Thanks for pointing this out. I should have caught this.
> With 0002, we are basically just throwing out the column lists
> entirely as we obtain the qualified identifiers from the catalog
> query. To fix this, I've adde
On Tue, Jan 22, 2019 at 11:21:32PM +, Bossart, Nathan wrote:
> On 1/21/19, 10:08 PM, "Michael Paquier" wrote:
> > On Mon, Jan 21, 2019 at 10:09:09PM +, Bossart, Nathan wrote:
> >> Here's a new patch set that should address the feedback in this
> >> thread. The changes in this version incl
On Mon, Jan 21, 2019 at 10:09:09PM +, Bossart, Nathan wrote:
> Here's a new patch set that should address the feedback in this
> thread. The changes in this version include:
>
> - 0001 is a small fix to the 'vacuumdb --disable-page-skipping'
>documentation. My suggestion is to keep it s
On Wed, Jan 9, 2019 at 1:33 PM Michael Paquier wrote:
>
> On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote:
> > Since pg_(total)_relation_size() returns 0 for parent table the
> > specifying the parent table to vacuumdb with --min-relation-size
> > always does nothing. Maybe we will
On 1/8/19, 10:34 PM, "Michael Paquier" wrote:
> On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote:
>> Since pg_(total)_relation_size() returns 0 for parent table the
>> specifying the parent table to vacuumdb with --min-relation-size
>> always does nothing. Maybe we will need to deal
On Wed, Jan 09, 2019 at 10:33:00AM +0900, Masahiko Sawada wrote:
> Since pg_(total)_relation_size() returns 0 for parent table the
> specifying the parent table to vacuumdb with --min-relation-size
> always does nothing. Maybe we will need to deal with this case when a
> function returning whole pa
On Wed, Jan 9, 2019 at 10:06 AM Michael Paquier wrote:
>
> On Tue, Jan 08, 2019 at 06:46:11PM +, Bossart, Nathan wrote:
> > This was done in order to maintain the current behavior that
> > appendQualifiedRelation() gives us. I found that skipping the
> > search_path handling here forced us to
On Tue, Jan 08, 2019 at 06:46:11PM +, Bossart, Nathan wrote:
> This was done in order to maintain the current behavior that
> appendQualifiedRelation() gives us. I found that skipping the
> search_path handling here forced us to specify the schema in the
> argument for --table in most cases.
On 1/7/19, 1:12 AM, "Michael Paquier" wrote:
> I have been looking at the patch set, and 0001 can actually happen
> only once 0005 is applied because this modifies the query doing on
> HEAD a full scan of pg_class which would include at least catalog
> tables so it can never be empty. For this re
On Mon, Jan 07, 2019 at 06:10:21PM +0900, Masahiko Sawada wrote:
> 0002 and 0003 are merged and posted by Michael-san and it looks good
> to me, so I've looked at the 0001, 0004, 0005 and 0006 patches. Here
> is a few review comments.
I have done another round on 0002/0003 (PQfinish was lacking af
On Sat, Jan 5, 2019 at 8:50 AM Bossart, Nathan wrote:
>
> On 12/21/18, 11:14 AM, "Bossart, Nathan" wrote:
> > On 12/21/18, 10:51 AM, "Robert Haas" wrote:
> >> On Thu, Dec 20, 2018 at 11:48 AM Bossart, Nathan
> >> wrote:
> >>> Either way, we'll still have to decide whether to fail or to silentl
On Fri, Jan 04, 2019 at 11:49:46PM +, Bossart, Nathan wrote:
> Here's an updated set of patches with the following changes:
>
> - 0002 adds the parenthesized syntax for ANALYZE.
> - 0003 adds DISABLE_PAGE_SKIPPING for VACUUM.
> - 0003 also ensures SKIP_LOCKED is applied for --analyze-only.
On Fri, Jan 04, 2019 at 11:49:46PM +, Bossart, Nathan wrote:
> 0004 introduces a slight change to existing behavior. Currently, if
> you specify a missing table, vacuumdb will process each table until
> it reaches the nonexistent one, at which point it will fail. After
> 0004 is applied, vacu
On 12/21/18, 10:51 AM, "Robert Haas" wrote:
> On Thu, Dec 20, 2018 at 11:48 AM Bossart, Nathan wrote:
>> Either way, we'll still have to decide whether to fail or to silently
>> skip the option if you do something like specify --min-mxid-age for a
>> 9.4 server.
>
> +1 for fail.
Sounds good. I'
On Thu, Dec 20, 2018 at 11:48 AM Bossart, Nathan wrote:
> Either way, we'll still have to decide whether to fail or to silently
> skip the option if you do something like specify --min-mxid-age for a
> 9.4 server.
+1 for fail.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
On Wed, Dec 19, 2018 at 9:05 PM Michael Paquier wrote:
> > It does not seem clear whether the user wants us to process mytable
> > only if it is at least 1 GB, or if we should process mytable in
> > addition to any other relations over 1 GB. Either way, I think trying
> > to support these combina
On Thu, Dec 20, 2018 at 04:48:11PM +, Bossart, Nathan wrote:
> The --skip-locked option in vacuumdb is part of 0002, so I don't think
> there's much precedent here.
It looks like I was not looking at the master branch here ;)
> We do currently fall back to the
> unparenthesized syntax for VAC
Hi Michael,
Thanks for taking a look.
On 12/19/18, 8:05 PM, "Michael Paquier" wrote:
> On Wed, Dec 19, 2018 at 08:50:10PM +, Bossart, Nathan wrote:
>> If an option is specified for a server version that is not supported,
>> the option is silently ignored. For example, SKIP_LOCKED was only
>
On Wed, Dec 19, 2018 at 08:50:10PM +, Bossart, Nathan wrote:
> If an option is specified for a server version that is not supported,
> the option is silently ignored. For example, SKIP_LOCKED was only
> added to VACUUM and ANALYZE for v12. Alternatively, I think we could
> fail in vacuum_one_
27 matches
Mail list logo
