Hi all,
I found a typo in comment of blvacuum.c, so attach the patch for it.
--
Regards,
Eiji Seki
Fujitsu
fix_comment_in_blvacuum_c.patch
Description: fix_comment_in_blvacuum_c.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2017-02-28 04:56:43 Alvaro Herrera wrote:
> Here's a small patch to make a BRIN page range unsummarized. This is
> useful if data has been deleted, and the heap pages are now used for
> completely different data.
Hi,
I tried to apply your patch and use it. Applying and "make check" were
succ
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
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.
Hi all,
I found a wrong explanation about tsquery_phrase. I was slightly confused when
I tried to use it.
The current document explains tsquery_phrase as the followings[1].
- Function: tsquery_phrase(query1 tsquery, query2 tsquery, distance integer)
- Return Type: tsquery
- Description: make qu
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 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 results of the test that Haribabu m
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 &
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
iginal 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: GetOldestXminExtend for ignoring arbit
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 features
12 matches
Mail list logo