On Fri, May 6, 2016 at 12:45 AM, Amit Kapila
wrote:
> On Wed, May 4, 2016 at 7:48 PM, Kevin Grittner wrote:
>> On Tue, May 3, 2016 at 11:48 AM, Robert Haas
wrote:
>>
>>> OK, I see now: the basic idea here is that we can't prune based on the
>>> newer XID unless the page LSN is guaranteed to adva
On Wed, May 4, 2016 at 7:48 PM, Kevin Grittner wrote:
>
> On Tue, May 3, 2016 at 11:48 AM, Robert Haas
wrote:
>
> > OK, I see now: the basic idea here is that we can't prune based on the
> > newer XID unless the page LSN is guaranteed to advance whenever data
> > is removed. Currently, we attemp
On Tue, May 3, 2016 at 11:48 AM, Robert Haas wrote:
> OK, I see now: the basic idea here is that we can't prune based on the
> newer XID unless the page LSN is guaranteed to advance whenever data
> is removed. Currently, we attempt to limit bloat in non-unlogged,
> non-catalog tables. You're sa
On Tue, May 3, 2016 at 9:47 PM, Kevin Grittner wrote:
>
> On Tue, May 3, 2016 at 11:09 AM, Robert Haas
wrote:
> > On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner
wrote:
> >>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
> >>> you?
> >>
> >> Yes, I see three ways, the mo
On Tue, May 3, 2016 at 11:48 AM, Robert Haas wrote:
> OK, I see now: the basic idea here is that we can't prune based on the
> newer XID unless the page LSN is guaranteed to advance whenever data
> is removed. Currently, we attempt to limit bloat in non-unlogged,
> non-catalog tables. You're sa
On Tue, May 3, 2016 at 12:17 PM, Kevin Grittner wrote:
> On Tue, May 3, 2016 at 11:09 AM, Robert Haas wrote:
>> On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
you?
>>>
>>> Yes, I see three ways, the most obv
On Tue, May 3, 2016 at 11:09 AM, Robert Haas wrote:
> On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
>>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
>>> you?
>>
>> Yes, I see three ways, the most obvious of which is what Amit
>> suggested -- don't do early vacuu
On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
>> you?
>
> Yes, I see three ways, the most obvious of which is what Amit
> suggested -- don't do early vacuum on a table which has a hash index.
What do you mean by "e
On Tue, May 3, 2016 at 10:45 AM, Bruce Momjian wrote:
> On Mon, May 2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote:
>> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote:
>> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila
>> > wrote:
>> >>
>> >> Currently we do the test for old snapshot (Test
On Mon, May 2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote:
> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote:
> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila
> > wrote:
> >>
> >> Currently we do the test for old snapshot (TestForOldSnapshot) for hash
> >> indexes while scanning them. Do
On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote:
> On Sun, May 1, 2016 at 12:05 PM, Amit Kapila wrote:
>>
>> Currently we do the test for old snapshot (TestForOldSnapshot) for hash
>> indexes while scanning them. Does this test makes any sense for hash
>> indexes considering LSN on hash index
On Sun, May 1, 2016 at 12:05 PM, Amit Kapila
wrote:
> Currently we do the test for old snapshot (TestForOldSnapshot) for hash
> indexes while scanning them. Does this test makes any sense for hash
> indexes considering LSN on hash index will always be zero (as hash indexes
> are not WAL-logged)?
12 matches
Mail list logo