On 28 May 2013 15:15, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 25, 2013 at 6:14 AM, Simon Riggs si...@2ndquadrant.com 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
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_upgrade,
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 Sat, May 25, 2013 at 6:14 AM, Simon Riggs si...@2ndquadrant.com 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,
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 have
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 already
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
of
On Tue, May 28, 2013 at 12:29 PM, Josh Berkus j...@agliodbs.com 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
On 05/25/2013 01:14 PM, Simon Riggs wrote:
On 24 May 2013 17:00, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com
wrote:
[all-visible cannot restore hint
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
On 05/24/2013 07:00 PM, Robert Haas wrote:
On Fri, May 24, 2013 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com
wrote:
[all-visible cannot restore hint bits without FPI because of torn pages]
I haven't yet thought
On 24 May 2013 17:00, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com
wrote:
[all-visible cannot restore hint bits without FPI because of torn pages]
I
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. We
On 2013-05-23 22:09:02 -0400, Robert Haas wrote:
On Thu, May 23, 2013 at 1:51 PM, Andres Freund and...@2ndquadrant.com 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
On Fri, May 24, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com 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
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 vacuum
On Fri, May 24, 2013 at 11:29 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 24, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com
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
On Fri, May 24, 2013 at 11:52 AM, Andres Freund and...@2ndquadrant.com 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
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 FPI
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
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
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
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 we
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 Thu, May 23, 2013 at 1:51 PM, Andres Freund and...@2ndquadrant.com 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
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 vacuum
26 matches
Mail list logo
