On Wed, Jun 8, 2011 at 1:19 AM, Pavan Deolasee pavan.deola...@gmail.com wrote:
I went on to create a WIP patch based on our discussion. There are
couple of issues that I stumbled upon while testing it.
1. The start-of-index-vacuum LSN that we want to track must be noted
even before the heap
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
So are there any other objections/suggestions ? Anyone else cares to
look at the brief design that we discussed above ? Otherwise, I would
go ahead and work on this in the coming days. Of course, I will keep
the
On Thu, May 26, 2011 at 9:40 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
Having said that, it doesn't excite me too much because I
think we should do the dead line pointer reclaim operation during page
pruning and we are already holding cleanup
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Thu, May 26, 2011 at 9:40 AM, Robert Haas robertmh...@gmail.com wrote:
Currently, I believe the only way a page can get marked all-visible is
by vacuum. But if we make this change, then it would be possible for
On Thu, May 26, 2011 at 6:40 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
There are some other issues that we should think about too. Like
recording free space and managing visibility map. The free space is
recorded in the second pass pass today, but I don't see any reason why
that
On Thu, May 26, 2011 at 8:57 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Thu, May 26, 2011 at 9:40 AM, Robert Haas robertmh...@gmail.com wrote:
Currently, I believe the only way a page can get marked
On Tue, May 24, 2011 at 10:59 PM, Robert Haas robertmh...@gmail.com wrote:
So, first of all, thanks for putting some effort and thought into
this. Despite the large number of improvements in this area in 8.3
and 8.4, this is still a pain point, and it would be really nice to
find a way to
On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
The biggest gripe today is that vacuum needs two heap scans and each scan
dirties the buffer.
That's not that clear to me. The debate usually stalls because we
don't have sufficient info from real world analysis of
On Wed, May 25, 2011 at 7:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
The biggest gripe today is that vacuum needs two heap scans and each scan
dirties the buffer.
That's not that clear to me. The debate
On Wed, May 25, 2011 at 1:27 PM, Robert Haas robertmh...@gmail.com wrote:
At the moment we scan indexes if we have 0 rows to remove, which is
probably wasteful. Perhaps it would be better to keep a running total
of rows to remove, by updating pg_stats, then when we hit a certain
threshold in
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
But instead of allocating permanent space in the page header, which would
both reduce (admittedly only by 8 bytes) the amount of space available
for tuples, and more significantly have the effect of breaking on-disk
On Wed, May 25, 2011 at 7:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
But instead of allocating permanent space in the page header, which would
both reduce (admittedly only by 8 bytes) the amount of space
On Wed, May 25, 2011 at 5:57 PM, Robert Haas robertmh...@gmail.com wrote:
Alternatively, it's possible that we'd be better off vacuuming the
table more often (say, autovacuum_vacuum_scale_factor=0.10 or 0.08 or
something) but only doing the index scans every once in a while when
enough dead
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I'm confused. A major point of the approach I was proposing was to
avoid having to move tuples around.
Well, I am not sure how you can always guarantee to make space
available for the LSN without moving tuples ,
Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I think if are reclaiming LP_DEAD line pointers only while
defragmenting the page, we can always reclaim the space for the LSN,
On Wed, May 25, 2011 at 12:48 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I think if are reclaiming LP_DEAD line pointers only
On Wed, May 25, 2011 at 10:36 PM, Robert Haas robertmh...@gmail.com wrote:
I don't see how you'd store
anything in the hole without it being in a fixed place, where it would
eventually be hit by either the line pointer array or tuple data.
The point is that it doesn't matter. Suppose we
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I think the point is you can not *always* put it just after the line
pointer array without possibly shuffling the tuples. Remember we need
to put the LSN when the dead line pointer is generated because we
decided
On Wed, May 25, 2011 at 11:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
Now, there
is no way you can store is after the line pointer array without moving
the live tuple somewhere else.
So far I agree. But don't we always defragment
On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Agreed. The only thing I'm trying to do further is to avoid the need
for a reshuffle when the special LSN storage is reclaimed.
Ah ok. That was never clear from your initial emails or may be I
mis-read.
Sorry,
Hi All,
Some of the ideas regarding vacuum improvements were discussed here:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00863.php
http://archives.postgresql.org/pgsql-patches/2008-06/msg00059.php
A recent thread was started by Robert Haas, but I don't know if we logically
concluded
So, first of all, thanks for putting some effort and thought into
this. Despite the large number of improvements in this area in 8.3
and 8.4, this is still a pain point, and it would be really nice to
find a way to make some further improvements.
On Tue, May 24, 2011 at 2:58 AM, Pavan Deolasee
22 matches
Mail list logo
