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
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 not to change the
behavior of GetOldestXmin.
This change will be useful for
28 matches
Mail list logo