On 22 March 2017 at 03:42, Haribabu Kommi wrote:
>
>
> On Wed, Mar 22, 2017 at 1:53 PM, Seki, Eiji
> wrote:
>>
>>
>> Thank you for your review, again.
>>
>> I think your proposals are better, so I reflected them.
>
>
> Thanks for the updated
On Wed, Mar 22, 2017 at 1:53 PM, Seki, Eiji
wrote:
>
> Thank you for your review, again.
>
> I think your proposals are better, so I reflected them.
Thanks for the updated patch. Patch looks good to me.
I marked it as "ready for committer".
While reviewing this
On 2017-03-21 07:46:47 Haribabu Kommi wrote:
>On Tue, Mar 21, 2017 at 3:16 PM, Seki, Eiji wrote:
>+/* Use these flags in GetOldestXmin as "flags" */
>
>How about some thing like the following.
>/* Use the following flags as an input "flags" to GetOldestXmin function */
>
On Tue, Mar 21, 2017 at 3:16 PM, Seki, Eiji
wrote:
>
>
> Thank you for you review.
>
> I reflected your comment and attach the updated patch.
Thanks for the updated patch.
+/* Use these flags in GetOldestXmin as "flags" */
How about some thing like the following.
/*
On 2017-02-24 04:17:20 Haribabu Kommi wrote:
>On Fri, Feb 24, 2017 at 3:17 PM, Seki, Eiji
>
>wrote:
>
>>
>> Thank you for your comments.
>>
>> I reflected these comments to the attached patch. And I renamed IGNORE_XXX
>> flags to PROCARRAY_XXX flags.
>
>
On Thu, Mar 16, 2017 at 12:29 AM, Haribabu Kommi
wrote:
> On Fri, Feb 24, 2017 at 3:17 PM, Seki, Eiji
> wrote:
>> Thank you for your comments.
>>
>> I reflected these comments to the attached patch. And I renamed IGNORE_XXX
>> flags to
On Fri, Feb 24, 2017 at 3:17 PM, Seki, Eiji
wrote:
>
> Thank you for your comments.
>
> I reflected these comments to the attached patch. And I renamed IGNORE_XXX
> flags to PROCARRAY_XXX flags.
I checked the latest patch and I have some comments.
+static int
on 2017-02-24 04:41:09 Simon Riggs wrote:
> ...you didn't comment at all on the accuracy and usefulness of the
> gathered statistics, when the sample is biased towards non-updated
> data.
In my understanding, the sample for statistics is not biased at least in our
use case because the conversion
On 14 February 2017 at 14:19, Seki, Eiji wrote:
> Hi all,
>
> I propose the patch that adds a function GetOldestXminExtended that is like
> GetOldestXmin but can ignore arbitrary vacuum flags. And then, rewrite
> GetOldestXmin to use it. Note that this is done so as
On 16 February 2017 at 05:24, Seki, Eiji wrote:
> Simon Riggs wrote:
>> Please persuade us with measurements that allowing this impact on
>> ANALYZE would really improve performance at least in your case, and
>> also examine the effect of
On 2017-02-15 17:27:11 Robert Haas wrote:
> On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby
> wrote:
> > On 2/14/17 3:13 AM, Seki, Eiji wrote:
> >> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
> >
> >
> > My impression is that most
Simon Riggs wrote:
> Please persuade us with measurements that allowing this impact on
> ANALYZE would really improve performance at least in your case, and
> also examine the effect of this on the accuracy and usefulness of the
> gathered statistics.
I explain
On Thu, Feb 16, 2017 at 10:48 AM, Haribabu Kommi
wrote:
> Because of the above reason, we need a new API or some change in API
> to provide the Oldest xmin by ignoring the ANALYZE transactions, so that
> it will reduce the size of WOS and improves the VCI query
On Wed, Feb 15, 2017 at 11:35 PM, Amit Kapila
wrote:
> On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji
> wrote:
> > Amit Kapila wrote:
> >> How will you decide just based on oldest xmin whether the tuple is
> visible or not? How will you take
Andres Freund writes:
> On 2017-02-15 12:27:11 -0500, Robert Haas wrote:
>> I agree; also, many years ago a guy named Tom Lane told me that flags
>> argument should typically be declared as type "int". I've followed
>> that advice ever since.
> Why is that? I think uint
On 2017-02-15 12:27:11 -0500, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby wrote:
> > On 2/14/17 3:13 AM, Seki, Eiji wrote:
> >> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
> >
> >
> > My impression is that most other places
On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby wrote:
> On 2/14/17 3:13 AM, Seki, Eiji wrote:
>> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
>
>
> My impression is that most other places that do this sort of thing just call
> the argument 'flags',
On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji wrote:
> Amit Kapila wrote:
>> How will you decide just based on oldest xmin whether the tuple is visible
>> or not? How will you take decisions about tuples which have xmax set?
>
> In our use case, GetOldestXmin is used by
Michael Paquier wrote:
> On Wed, Feb 15, 2017 at 5:32 PM, Simon Riggs wrote:
> > Please persuade us with measurements that allowing this impact on
> > ANALYZE would really improve performance at least in your case, and
> > also examine the effect of this on the accuracy and
On Wed, Feb 15, 2017 at 5:32 PM, Simon Riggs wrote:
> Please persuade us with measurements that allowing this impact on
> ANALYZE would really improve performance at least in your case, and
> also examine the effect of this on the accuracy and usefulness of the
> gathered
On 14 February 2017 at 06:19, Seki, Eiji wrote:
> In our benchmark, we found that waiting an ANALYZE process created by
> autovacuum daemon often has a significant impact to the performance although
> the waited process do only reading as to the table.
...
> I'm not
Jim Nasby wrote:
> On 2/14/17 3:13 AM, Seki, Eiji wrote:
> > +extern TransactionId GetOldestXmin(Relation rel, uint8
> > ignoreFlags);
>
> My impression is that most other places that do this sort of thing just call
> the argument 'flags', so as not to "lock in" a single idea of what the
Amit Kapila wrote:
> How will you decide just based on oldest xmin whether the tuple is visible or
> not? How will you take decisions about tuples which have xmax set?
In our use case, GetOldestXmin is used by an original maintainer process[es] to
an original control table[s]. The table can be
On 2/14/17 3:13 AM, Seki, Eiji wrote:
+extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
My impression is that most other places that do this sort of thing just
call the argument 'flags', so as not to "lock in" a single idea of what
the flags are for. I can't readily
On Tue, Feb 14, 2017 at 11:49 AM, Seki, Eiji wrote:
> Hi all,
>
> I propose the patch that adds a function GetOldestXminExtended that is like
> GetOldestXmin but can ignore arbitrary vacuum flags. And then, rewrite
> GetOldestXmin to use it. Note that this is done so
_DEFAULT)
Regards,
Eiji Seki
Fujitsu.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
Sent: Tuesday, February 14, 2017 3:43 PM
To: Seki, Eiji/関 栄二
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal: GetOl
On Tue, Feb 14, 2017 at 3:19 PM, Seki, Eiji wrote:
> This change will be useful for features that only reads rows that are visible
> by all transactions and could not wait specific processes (VACUUM, ANALYZE,
> etc...) for performance. Our company (Fujitsu) is
27 matches
Mail list logo