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
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
On 2017-03-21 07:46:47 Haribabu Kommi wrote:
>On Tue, Mar 21, 2017 at 3:16 PM, Seki, Eiji <seki.e...@jp.fujitsu.com> wrote:
>+/* Use these flags in GetOldestXmin as "flags" */
>
>How about some thing like the following.
>/* Use the following flags as an input &q
On 2017-02-24 04:17:20 Haribabu Kommi wrote:
>On Fri, Feb 24, 2017 at 3:17 PM, Seki, Eiji
><seki(dot)eiji(at)jp(dot)fujitsu(dot)com>
>wrote:
>
>>
>> Thank you for your comments.
>>
>> I reflected these comments to the attached patch. And I renamed
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
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
> <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> > On 2/14/17 3:13 AM, Seki, Eiji wrote:
> >> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
> >
&
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
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 "l
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
_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
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
12 matches
Mail list logo