On Wed, Jun 8, 2011 at 1:19 AM, Pavan Deolasee 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 scan is started. This
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
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 list posted about an
On Thu, May 26, 2011 at 8:57 AM, Pavan Deolasee
wrote:
> On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
> wrote:
>> On Thu, May 26, 2011 at 9:40 AM, Robert Haas wrote:
>>
>>> Currently, I believe the only way a page can get marked all-visible is
>>> by vacuum. But if we make this change, then
On Thu, May 26, 2011 at 6:40 AM, Pavan Deolasee
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 can't be moved to
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
wrote:
> On Thu, May 26, 2011 at 9:40 AM, Robert Haas 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
>> a HOT cleanup to encounter a situati
On Thu, May 26, 2011 at 9:40 AM, Robert Haas 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 lock at that ti
On Wed, May 25, 2011 at 11:51 PM, Pavan Deolasee
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, I must not have ex
On Wed, May 25, 2011 at 11:39 PM, Robert Haas 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 immediately after
> pr
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
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 to prune away the dead
On Wed, May 25, 2011 at 10:36 PM, Robert Haas 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 put it just aft
On Wed, May 25, 2011 at 12:48 PM, Alvaro Herrera
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
>> wrote:
>
>> > I think if are reclaiming LP_DEAD line pointers only while
>> > defragmenting the page, we can alwa
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
> wrote:
> > I think if are reclaiming LP_DEAD line pointers only while
> > defragmenting the page, we can always reclaim the space for the LSN,
> > irrespective of where we s
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
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 , irrespective of w
On Wed, May 25, 2011 at 5:57 PM, Robert Haas 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 line pointers hav
On Wed, May 25, 2011 at 7:20 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
> 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 signific
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
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
>> compatibility,
On Wed, May 25, 2011 at 1:27 PM, Robert Haas 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 total we can
On Wed, May 25, 2011 at 7:31 AM, Simon Riggs wrote:
> On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
> 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 s
On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
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 where the time
goes.
On Tue, May 24, 2011 at 10:59 PM, Robert Haas 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 make some further im
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
w
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 t
22 matches
Mail list logo
