On 28 May 2013 15:15, Robert Haas wrote:
> On Sat, May 25, 2013 at 6:14 AM, Simon Riggs wrote:
>> I think the right way is actually to rethink and simplify all this
>> complexity of Freezing/Pruning/Hinting/Visibility
>
> I agree, but I think that's likely to have to wait until we get a
> plugga
On Tue, 2013-05-28 at 09:29 -0700, Josh Berkus wrote:
> - it would prevent us from getting rid of allvisible, which has a
> documented and known write overhead
It would? I don't think these proposals are necessarily in conflict.
It's not entirely clear to me how they fit together in detail, but it
On Tue, 2013-05-28 at 19:51 -0400, Robert Haas wrote:
> > If we just wanted to reduce read cost, why not just take a simpler
> > approach and give the visibility map a "isfrozen" bit? Then we'd know
> > which pages didn't need rescanning without nearly as much complexity.
>
> That would break pg_
On Tue, May 28, 2013 at 12:29 PM, Josh Berkus wrote:
> On 05/28/2013 07:17 AM, Andres Freund wrote:
>> On 2013-05-26 16:58:58 -0700, Josh Berkus wrote:
>>> I was talking this over with Jeff on the plane, and we wanted to be
>>> clear on your goals here: are you looking to eliminate the *write* co
On 2013-05-28 09:29:26 -0700, Josh Berkus wrote:
> On 05/28/2013 07:17 AM, Andres Freund wrote:
> > On 2013-05-26 16:58:58 -0700, Josh Berkus wrote:
> >> I was talking this over with Jeff on the plane, and we wanted to be
> >> clear on your goals here: are you looking to eliminate the *write* cost
On 05/28/2013 07:17 AM, Andres Freund wrote:
> On 2013-05-26 16:58:58 -0700, Josh Berkus wrote:
>> I was talking this over with Jeff on the plane, and we wanted to be
>> clear on your goals here: are you looking to eliminate the *write* cost
>> of freezing, or just the *read* cost of re-reading al
On 2013-05-26 16:58:58 -0700, Josh Berkus wrote:
> I was talking this over with Jeff on the plane, and we wanted to be
> clear on your goals here: are you looking to eliminate the *write* cost
> of freezing, or just the *read* cost of re-reading already frozen pages?
Both. The latter is what I ha
On Sat, May 25, 2013 at 6:14 AM, Simon Riggs wrote:
>> One thought I had is that it might be beneficial to freeze when a page
>> ceases to be all-visible, rather than when it becomes all-visible.
>> Any operation that makes the page not-all-visible is going to emit an
>> FPI anyway, so we don't ha
Andres,
I was talking this over with Jeff on the plane, and we wanted to be
clear on your goals here: are you looking to eliminate the *write* cost
of freezing, or just the *read* cost of re-reading already frozen pages?
If just the latter, what about just adding a bit to the visibility map
to i
On 05/25/2013 01:14 PM, Simon Riggs wrote:
> On 24 May 2013 17:00, Robert Haas wrote:
>> On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
>>> On Fri, May 24, 2013 at 10:53 AM, Andres Freund
>>> wrote:
> [all-visible cannot restore hint bits without FPI because of torn pages]
I have
Andres,
> all visible is only set in vacuum and it determines which parts of a
> table will be scanned in a non full table vacuum. So, since we won't
> regularly start vacuum in the insert only case there will still be a
> batch of work at once. But nearly all of that work is *already*
> performed
On 24 May 2013 17:00, Robert Haas wrote:
> On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
>> On Fri, May 24, 2013 at 10:53 AM, Andres Freund
>> wrote:
[all-visible cannot restore hint bits without FPI because of torn pages]
>>>
>>> I haven't yet thought about this sufficiently yet. I
On 05/24/2013 07:00 PM, Robert Haas wrote:
> On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
>> On Fri, May 24, 2013 at 10:53 AM, Andres Freund
>> wrote:
[all-visible cannot restore hint bits without FPI because of torn pages]
>>> I haven't yet thought about this sufficiently yet. I th
On 2013-05-24 15:49:31 -0400, Josh Berkus wrote:
> If I understand your solution correctly, though, this doesn't really
> help the pathological case for freezing, which is the time-oriented
> append-only table. For data which isn't being used, allvisible won't be
> set either because it won't have
Andres,
If I understand your solution correctly, though, this doesn't really
help the pathological case for freezing, which is the time-oriented
append-only table. For data which isn't being used, allvisible won't be
set either because it won't have been read, no? Is it still cheaper to
set allv
On 5/24/13 9:53 AM, Andres Freund wrote:
We don't even necessarily need to log the hint bits for all items since
> >the redo for all_visible could make sure all items are hinted. The only
> >problem is knowing up to where we can truncate pg_clog...
>[all-visible cannot restore hint bits without
On Fri, May 24, 2013 at 11:52 AM, Andres Freund wrote:
>> The basic problem is that if the data is going to be removed before it
>> would have gotten frozen, then the extra FPIs are just overhead. In
>> effect, we're just deciding to freeze a lot sooner.
>
> Well, freezing without removing inform
On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
> On Fri, May 24, 2013 at 10:53 AM, Andres Freund
> wrote:
>>> [all-visible cannot restore hint bits without FPI because of torn pages]
>>
>> I haven't yet thought about this sufficiently yet. I think we might have
>> a chance of working aroun
On 2013-05-24 11:29:10 -0400, Robert Haas wrote:
> > But even if that means needing a full page write via the usual mechanism
> > for all visible if any hint bits needed to be set we are still out far
> > ahead of the current state imo.
> > * cleanup would quite possibly do an FPI shortly after in
On Fri, May 24, 2013 at 10:53 AM, Andres Freund wrote:
>> [all-visible cannot restore hint bits without FPI because of torn pages]
>
> I haven't yet thought about this sufficiently yet. I think we might have
> a chance of working around this, let me ponder a bit.
Yeah. I too feel like there migh
On 2013-05-23 22:09:02 -0400, Robert Haas wrote:
> On Thu, May 23, 2013 at 1:51 PM, Andres Freund wrote:
> > So, what I propose instead is basically:
> > 1) only vacuum non-all-visible pages, even when doing it for
> >anti-wraparound
>
> Check. We might want an option to force a scan of the w
On 05/23/2013 10:03 PM, Andres Freund wrote:
> On 2013-05-23 19:51:48 +0200, Andres Freund wrote:
>> We currently need to make sure we scanned the whole relation and have
>> frozen everything to have a sensible relfrozenxid for a relation.
>>
>> So, what I propose instead is basically:
>> 1) only v
On Thu, May 23, 2013 at 1:51 PM, Andres Freund wrote:
> So, what I propose instead is basically:
> 1) only vacuum non-all-visible pages, even when doing it for
>anti-wraparound
Check. We might want an option to force a scan of the whole relation.
> 2) When we can set all-visible guarantee t
On 2013-05-23 19:51:48 +0200, Andres Freund wrote:
> We currently need to make sure we scanned the whole relation and have
> frozen everything to have a sensible relfrozenxid for a relation.
>
> So, what I propose instead is basically:
> 1) only vacuum non-all-visible pages, even when doing it for
On 2013-05-23 19:51:48 +0200, Andres Freund wrote:
> I think that the existence of hint bits and the crash safe visibility
> maps should provide sufficient tooling to make freezing unneccessary
> without loosing much information for debugging if we modify the way
> vacuum works a bit.
> That way w
Hi,
after having discussed $subject shortly over dinner yesterday, while I
should have been preparing the slides for my talk I noticed that there
might be a rather easy way to get rid of freezing.
I think that the existence of hint bits and the crash safe visibility
maps should provide sufficient
26 matches
Mail list logo
