Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-22 Thread Simon Riggs
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-21 Thread Haribabu Kommi
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-21 Thread Seki, Eiji
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 */ >

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-21 Thread Haribabu Kommi
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. /*

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-20 Thread Seki, Eiji
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. > >

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-16 Thread Robert Haas
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-03-15 Thread Haribabu Kommi
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-27 Thread Seki, Eiji
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-23 Thread Craig Ringer
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-23 Thread Simon Riggs
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-23 Thread Seki, Eiji
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Seki, Eiji
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Michael Paquier
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Haribabu Kommi
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Tom Lane
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Andres Freund
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Robert Haas
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',

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Amit Kapila
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Alvaro Herrera
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Michael Paquier
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-15 Thread Simon Riggs
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-14 Thread Seki, Eiji
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-14 Thread Seki, Eiji
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-14 Thread Jim Nasby
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-14 Thread Amit Kapila
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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-14 Thread Seki, Eiji
_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

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

2017-02-13 Thread Michael Paquier
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