On 10/3/18, 7:10 PM, "Michael Paquier" wrote:
> Thanks, I have committed the patch, after minor tweaks to the docs.
Thanks!
> Mainly, in the VACUUM page, I have added a mention that VACUUM ANALYZE
> can block for row sampling. I have also removed for now the set of
> recommendations the patch a
On Wed, Oct 03, 2018 at 04:20:42PM +, Bossart, Nathan wrote:
> Here is what I have so far for the docs:
>
> [snip]
Thanks, I have committed the patch, after minor tweaks to the docs.
Mainly, in the VACUUM page, I have added a mention that VACUUM ANALYZE
can block for row sampling. I have also
On Tue, Oct 02, 2018 at 02:22:42AM +, Bossart, Nathan wrote:
> On 10/1/18, 7:07 PM, "Michael Paquier" wrote:
>> On Mon, Oct 01, 2018 at 03:37:01PM +, Bossart, Nathan wrote:
>>> Without the find_all_inheritors() stuff, I think we would just need to
>>> modify the ANALYZE documentation patch
On Mon, Oct 01, 2018 at 03:37:01PM +, Bossart, Nathan wrote:
> Good idea. This patch looks good to me.
Thanks, I have pushed this one now.
> Without the find_all_inheritors() stuff, I think we would just need to
> modify the ANALYZE documentation patch to say something like
>
> Specifie
On 9/27/18, 2:52 AM, "Michael Paquier" wrote:
> Thanks for the new patches. So I have begun looking at the full set,
> beginning by 0001 which introduces a new common routine to get the
> elevel associated to a skipped relation. I have been chewing on this
> one, and I think that the patch could
On Wed, Sep 05, 2018 at 03:24:21PM +, Bossart, Nathan wrote:
> And here it is. Here is a summary of the notable changes:
>
> 1) Patches v8-0003 and v8-0008 have been discarded. These patches
> added SKIP_LOCKED behavior when opening a relation's indexes.
> Instead, I've documented t
On Tue, Sep 04, 2018 at 03:49:09PM +, Bossart, Nathan wrote:
> Yes. I've started working on this again, but the new patch set is
> probably still a few days out.
Thanks, Nathan.
--
Michael
signature.asc
Description: PGP signature
On 9/3/18, 6:20 PM, "Michael Paquier" wrote:
> Nathan, could you rebase your patch set? From what I can see the last
> patch set applies with one conflict, and it would be nice for clarity to
> split the routines for analyze, vacuum and cluster into separate places.
> Similar to what is done with
On Sun, Jul 29, 2018 at 10:56:24PM +, Bossart, Nathan wrote:
> Since vacuum_rel() already obtains an AccessExclusiveLock on the
> relation for VACUUM FULL, we might be able to skip altering
> cluster_rel(). I think we will need to alter it if we are going to
> add SKIP LOCKED to CLUSTER, thoug
On 7/24/18, 8:07 PM, "Michael Paquier" wrote:
> Hm... I have not imagined this part but adding a new layer is sort of
> ugly, and an extra one would be needed for CLUSTER as well, in which
> case adding cluster-related logs into vacuum.c introduces a circular
> dependency with cluster.c. What ab
On Tue, Jul 24, 2018 at 05:21:25PM +, Bossart, Nathan wrote:
> Here is a patch for refactoring the ereport() calls out of
> vacuum_rel() and analyze_rel(). I've kept all four possible log
> statements separated for ease of translation. I considered
> simplifying these statements by replacing
On Mon, Jul 23, 2018 at 02:27:48PM +, Bossart, Nathan wrote:
> Sorry for the delay on these patches! This is nearly identical to
> what I started writing last night, so it looks good to me.
Thanks for double-checking. I have pushed this one to move on with the
rest of the feature.
> +typede
On 7/22/18, 10:12 PM, "Michael Paquier" wrote:
> The refactoring for CLUSTER is pretty obvious, and makes the API a bit
> cleaner, so attached is a proposal of patch to do so. Thoughts?
Sorry for the delay on these patches! This is nearly identical to
what I started writing last night, so it lo
On Thu, Jul 19, 2018 at 10:54:23AM +0900, Michael Paquier wrote:
> If you can get this refactoring done, let's look into getting those two
> parts committed first to simplify the next steps. No need to extend the
> grammar of cluster either. The set of options for CLUSTER should be a
> separate e
On Wed, Jul 18, 2018 at 04:58:48PM +, Bossart, Nathan wrote:
> On 7/17/18, 1:22 AM, "Michael Paquier" wrote:
> Perhaps we could extend RangeVarGetRelidExtended() to only lock if
> has_subclass() is true. However, I also understand Robert's position
> on calling RangeVarGetRelidExtended() with
Hi Michael,
Thanks for taking a look.
On 7/17/18, 1:22 AM, "Michael Paquier" wrote:
> The first thing which is striking me is that we may actually *not* want
> to check for lock skipping within expand_vacuum_rel() as that's mainly a
> function aimed at building the relations which are going to b
On Tue, Jul 17, 2018 at 2:21 AM, Michael Paquier wrote:
> For this part, it seems to me that we can do better than what is in
> HEAD:
> - Call RangeVarGetRelidExtended without lock.
I haven't been following this work closely, but I just want to point
out that the reason why RangeVarGetRelidExtend
On Thu, Jul 12, 2018 at 02:37:28PM +0900, Michael Paquier wrote:
> On Wed, Jun 13, 2018 at 08:29:12PM +, Bossart, Nathan wrote:
>> Previous thread:
>> https://postgr.es/m/4BC0F3CD-F4B5-4F23-AADB-80607F9E4B4E%40amazon.com
>>
>> This is a new thread for tracking the
On Wed, Jun 13, 2018 at 08:29:12PM +, Bossart, Nathan wrote:
> Previous thread:
> https://postgr.es/m/4BC0F3CD-F4B5-4F23-AADB-80607F9E4B4E%40amazon.com
>
> This is a new thread for tracking the work to add SKIP LOCKED to
> VACUUM and ANALYZE. I've attached a rebased s
19 matches
Mail list logo
