On 3 December 2012 17:37, Pavan Deolasee wrote:
> I was looking at the code when the following tiny bit caught my attention.
> In vacuumlazy.c, we release the pin on the final VM page at line number 972.
>
> 954 if (vacrelstats->num_dead_tuples > 0)
> 955 {
> 956 /* Log cleanup
I was looking at the code when the following tiny bit caught my attention.
In vacuumlazy.c, we release the pin on the final VM page at line number 972.
954 if (vacrelstats->num_dead_tuples > 0)
955 {
956 /* Log cleanup info before we touch indexes */
957 vacuum_log_clea
On Thu, May 5, 2011 at 2:20 PM, Merlin Moncure wrote:
> On Thu, May 5, 2011 at 2:00 PM, Kevin Grittner
> wrote:
>> Merlin Moncure wrote:
>>
>>> a small cache that remembers the commit/cancel status of recently
>>> seen transactions.
>>
>> How is that different from the head of the clog SLRU?
>
>
On Thu, May 5, 2011 at 2:00 PM, Kevin Grittner
wrote:
> Merlin Moncure wrote:
>
>> a small cache that remembers the commit/cancel status of recently
>> seen transactions.
>
> How is that different from the head of the clog SLRU?
several things:
*) any slru access requires lock (besides the lock
Merlin Moncure wrote:
> a small cache that remembers the commit/cancel status of recently
> seen transactions.
How is that different from the head of the clog SLRU?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Thu, May 5, 2011 at 1:34 PM, Bruce Momjian wrote:
> Merlin Moncure wrote:
>> On Thu, May 5, 2011 at 11:59 AM, Bruce Momjian wrote:
>> > There has been a lot of recent discussion about the visibility map (for
>> > index-only scans) and hint bits (trying to avoid double-writing a
>> > table).
>>
On Thu, May 5, 2011 at 12:59 PM, Bruce Momjian wrote:
> I wonder if we could fix both of these at the same time. Once the
> visibility map is reliable, can we use that to avoid updating the hint
> bits on all rows on a page?
I don't think so. There are two problems:
1. If there is a long-runni
Merlin Moncure wrote:
> On Thu, May 5, 2011 at 11:59 AM, Bruce Momjian wrote:
> > There has been a lot of recent discussion about the visibility map (for
> > index-only scans) and hint bits (trying to avoid double-writing a
> > table).
>
> I still think a small tqual.c maintained cache of hint bi
On Thu, May 5, 2011 at 11:59 AM, Bruce Momjian wrote:
> There has been a lot of recent discussion about the visibility map (for
> index-only scans) and hint bits (trying to avoid double-writing a
> table).
I still think a small tqual.c maintained cache of hint bits will
effectively eliminate hint
There has been a lot of recent discussion about the visibility map (for
index-only scans) and hint bits (trying to avoid double-writing a
table).
I wonder if we could fix both of these at the same time. Once the
visibility map is reliable, can we use that to avoid updating the hint
bits on all ro
On Tue, Nov 23, 2010 at 3:42 AM, Heikki Linnakangas
wrote:
> That's an interesting idea. You pickyback setting the vm bit on the freeze
> WAL record, on the assumption that you have to write the freeze record
> anyway. However, if that assumption doesn't hold, because the tuples are
> deleted befo
On 22.11.2010 21:24, Robert Haas wrote:
Eh, so. Suppose - for the sake of argument - we do the following:
1. Allocate an additional infomask(2) bit that means "xmin is frozen,
no need to call XidInMVCCSnapshot()". When we freeze a tuple, we set
this bit in lieu of overwriting xmin. Note that
Can we just log the change of VM in log_heap_clean() for redo?
Thanks
--
GaoZengqi
pgf...@gmail.com
zengqi...@gmail.com
On Tue, Nov 23, 2010 at 3:24 AM, Robert Haas wrote:
> On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas
> wrote:
> >> I *think* that the answer to this parenthesized quest
On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas
wrote:
>> I *think* that the answer to this parenthesized question is "no".
>> When we vacuum a page, we set the LSN on both the heap page and the
>> visibility map page. Therefore, neither of them can get written to
>> disk until the WAL record
On 14/06/10 06:08, Robert Haas wrote:
visibilitymap.c begins with a long and useful comment - but this part
seems to have a bit of split personality disorder.
* Currently, the visibility map is not 100% correct all the time.
* During updates, the bit in the visibility map is cleared after re
visibilitymap.c begins with a long and useful comment - but this part
seems to have a bit of split personality disorder.
* Currently, the visibility map is not 100% correct all the time.
* During updates, the bit in the visibility map is cleared after releasing
* the lock on the heap page. Duri
Euler Taveira de Oliveira wrote:
Simon Riggs escreveu:
On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
Attached is a simple patch to only start skipping pages after 20
consecutive pages marked as visible in the visibility map. This doesn't
do any "look-ahead", so it will always s
Heikki Linnakangas wrote:
ITAGAKI Takahiro wrote:
- What relation are there between autovacuum_freeze_max_age,
vacuum_freeze_min_age and vacuum_freeze_table_age? If we increase
one of them, should we also increase the others?
Yeah, that's a fair question. I'll try to work a doc patch to ex
Simon Riggs escreveu:
> On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
>
>> Attached is a simple patch to only start skipping pages after 20
>> consecutive pages marked as visible in the visibility map. This doesn't
>> do any "look-ahead", so it will always scan the first 20 pages
On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
> Attached is a simple patch to only start skipping pages after 20
> consecutive pages marked as visible in the visibility map. This doesn't
> do any "look-ahead", so it will always scan the first 20 pages of a
> table before it star
Simon Riggs wrote:
On Tue, 2009-01-20 at 11:03 +0200, Heikki Linnakangas wrote:
- Are there some conditions where whole-table-scanning vacuum is
more
effective than vacuums using visibility map? If so, we should
switch
to full-scan *automatically*, without relying on user
configurations
On Tue, 2009-01-20 at 11:03 +0200, Heikki Linnakangas wrote:
> > - Are there some conditions where whole-table-scanning vacuum is
> more
> > effective than vacuums using visibility map? If so, we should
> switch
> > to full-scan *automatically*, without relying on user
> configurations.
>
> H
ITAGAKI Takahiro wrote:
Gregory Stark wrote:
I don't think we can perfectly capture the meaning of these GUCs in the
name. I think our goal should be to avoid confusion between them.
I was thinking it would be clearer if the options which control *when*
autovacuum fires off a worker consisten
Gregory Stark wrote:
> >> I don't think we can perfectly capture the meaning of these GUCs in the
> >> name. I think our goal should be to avoid confusion between them.
>
> I was thinking it would be clearer if the options which control *when*
> autovacuum fires off a worker consistently had so
Alvaro Herrera wrote:
Heikki Linnakangas escribió:
This patch adds a new column to pg_autovacuum, reflecting the new
vacuum_freeze_table_age GUC just like freeze_min_age column reflects
vacuum_freeze_min_age. If I commit this tomorrow, will I cause you a
lot of trouble with the reloptions patc
Heikki Linnakangas writes:
> Jeff Davis wrote:
>> On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
>>>
>>> I'm now leaning towards:
>>>
>>> autovacuum_freeze_max_age
>>> vacuum_freeze_table_age
>>> vacuum_freeze_min_age
>>>
>>> where autovacuum_freeze_max_age and vacuum_freeze_min_age
Heikki Linnakangas escribió:
> Alvaro, are you getting rid of pg_autovacuum in favor of the reloptions
> for 8.4?
That's the intention, yes.
> This patch adds a new column to pg_autovacuum, reflecting the new
> vacuum_freeze_table_age GUC just like freeze_min_age column reflects
> vacuum_free
Jeff Davis wrote:
On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
If the distinction you're making is that autovacuum_freeze_max_age
affects the launching of a vacuum rather than the behavior of a vacuum,
maybe we could incorporate the word "launch" like:
autovacuum_launch_freeze_th
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Also, is anything being done about the concern about 'vacuum storm'
explained below?
I'm interested too.
The additional "vacuum_freeze_table_age" (as I'm now calling it) setting
I discussed in a later thread should alleviate that somewhat. When a
Gregory Stark wrote:
> Bruce Momjian writes:
>
> > Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
> > when our wraparound limit is around 2B?
>
> I suggested raising it dramatically in the post you quote and Heikki pointed
> it controls the maximum amount of space the clo
Heikki Linnakangas wrote:
> >> Also, is anything being done about the concern about 'vacuum storm'
> >> explained below?
> >
> > I'm interested too.
>
> The additional "vacuum_freeze_table_age" (as I'm now calling it) setting
> I discussed in a later thread should alleviate that somewhat. When a
Gregory Stark wrote:
Bruce Momjian writes:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
I suggested raising it dramatically in the post you quote and Heikki pointed
it controls the maximum amount of space the clog will take. R
Bruce Momjian writes:
> Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
> when our wraparound limit is around 2B?
I suggested raising it dramatically in the post you quote and Heikki pointed
it controls the maximum amount of space the clog will take. Raising it to,
say, 80
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
> > when our wraparound limit is around 2B?
> >
>
> Presumably because of this (from the docs):
>
> "The commit status uses two bits per transaction, so if
> autovacuu
Bruce Momjian wrote:
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
Presumably because of this (from the docs):
"The commit status uses two bits per transaction, so if
autovacuum_freeze_max_age has its maximum allowed value
Would someone tell me why 'autovacuum_freeze_max_age' defaults to 200M
when our wraparound limit is around 2B?
Also, is anything being done about the concern about 'vacuum storm'
explained below?
---
Gregory Stark wrote:
>
On Fri, 2009-01-09 at 13:49 +0200, Heikki Linnakangas wrote:
> Thinking about this some more, I'm not too happy with those names
> either. vacuum_freeze_scan_age and autovacuum_freeze_scan_age don't mean
> quite the same thing, like vacuum_cost_delay and
> autovacuum_vacuum_cost_delay do, for ex
Jeff Davis wrote:
On Wed, 2009-01-07 at 09:34 +0200, Heikki Linnakangas wrote:
autovacuum_freeze_max_age -> autovacuum_freeze_scan_age
vacuum_freeze_max_age -> vacuum_freeze_scan_age
vacuum_freeze_min_age -> vacuum_freeze_tuple_age
*_scan_age settings control when the table is fully scanned
On Wed, 2009-01-07 at 09:34 +0200, Heikki Linnakangas wrote:
> autovacuum_freeze_max_age -> autovacuum_freeze_scan_age
> vacuum_freeze_max_age -> vacuum_freeze_scan_age
> vacuum_freeze_min_age -> vacuum_freeze_tuple_age
>
> *_scan_age settings control when the table is fully scanned to freeze
> t
Jeff Davis wrote:
On Mon, 2008-12-22 at 21:24 +0200, Heikki Linnakangas wrote:
Introduce new vacuum_freeze_max_age setting. Manual VACUUM will scan the
whole table and advance relfrozenxid, if relfrozenxid is older than
vacuum_freeze_max_age.
It's confusing to have two GUCs named vacuum_fre
On Mon, 2008-12-22 at 21:24 +0200, Heikki Linnakangas wrote:
> Introduce new vacuum_freeze_max_age setting. Manual VACUUM will scan the
> whole table and advance relfrozenxid, if relfrozenxid is older than
> vacuum_freeze_max_age.
>
It's confusing to have two GUCs named vacuum_freeze_min_age an
On Tue, Dec 23, 2008 at 4:24 AM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>>
>> Peter Eisentraut wrote:
>>>
>>> Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUU
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map
is ignore
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map
is ignored and all pages are scanned
Heikki Linnakangas wrote:
I think we need a threshold similar to autovacuum_freeze_max_age for
manual vacuums as well: vacuum_freeze_max_age. If you run VACUUM, and
relfrozenxid is older than vacuum_freeze_max_age, the visibility map is
ignored and all pages are scanned.
Would one parameter t
Zdenek Kotala writes:
> What's about add second bit which mark frozen page (all tuples have freeze
> XID)? It should avoid full scan, but extend size of map.
That would only really work if you have a very static table where entire pages
get frozen and stay frozen long before the freeze_max_age i
Zdenek Kotala wrote:
What's about add second bit which mark frozen page (all tuples have
freeze XID)? It should avoid full scan, but extend size of map.
First of all, we'd still have to make the decision of when to scan pages
that need freezing, and when to only scan pages that have dead tuple
What's about add second bit which mark frozen page (all tuples have freeze XID)?
It should avoid full scan, but extend size of map.
Zdenek
Heikki Linnakangas napsal(a):
The way VACUUM works with the visibility map is that if any pages are
skipped, relfrozenxid can't b
The way VACUUM works with the visibility map is that if any pages are
skipped, relfrozenxid can't be updated. That means that plain VACUUM
won't advance relfrozenxid, and doesn't protect from XID wraparound.
We discussed this in the context of autovacuum before, and we have that
covered now. A
Tom Lane wrote:
I think your previous sketch is right: suppress update of reltuples (and
relpages) from a partial vacuum scan, and ensure that the analyze phase
is allowed to do it instead if it happens during VACUUM ANALYZE.
We also mustn't reset n_live_tuples in pgstat in partial vacuum.
Com
On Mon, 15 Dec 2008, Greg Stark wrote:
I wonder if we should switch to keeping reltuplesperpage instead.
It would be preferrable to not touch the user side of reltuples if
possible, since it's the only instant way to get a good estimate of the
number of rows in a table right now. That's bee
Heikki Linnakangas writes:
> Greg Stark wrote:
>> I wonder if we should switch to keeping reltuplesperpage instead. Then a
>> partial vacuum could update it by taking the average number of tuples
>> per page forbthe pages it saw. Perhaps adjusting it to the weights
>> average between the old va
Greg Stark wrote:
I wonder if we should switch to keeping reltuplesperpage instead. Then a
partial vacuum could update it by taking the average number of tuples
per page forbthe pages it saw. Perhaps adjusting it to the weights
average between the old value and the new value based on how many p
I wonder if we should switch to keeping reltuplesperpage instead. Then
a partial vacuum could update it by taking the average number of
tuples per page forbthe pages it saw. Perhaps adjusting it to the
weights average between the old value and the new value based on how
many pages were seen
Heikki Linnakangas wrote:
Ned T. Crigler wrote:
It appears that the visibility map patch is causing pg_class.reltuples
to be
set improperly after a vacuum. For example, it is set to 0 if the map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated u
Ned T. Crigler wrote:
It appears that the visibility map patch is causing pg_class.reltuples to be
set improperly after a vacuum. For example, it is set to 0 if the map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated unless every page was scanned
It appears that the visibility map patch is causing pg_class.reltuples to be
set improperly after a vacuum. For example, it is set to 0 if the map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated unless every page was scanned during
the vacuum?
--
Guillaume Smet wrote:
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
First run - without visibility maps, timing of vacuums:
Time: 267844.822 ms
Time: 138854.592 ms
Time: 305467.950 ms
Time: 487133.179 ms
Second run - on head:
Time: 252218.609 ms
Time: 23
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
> First run - without visibility maps, timing of vacuums:
> Time: 267844.822 ms
> Time: 138854.592 ms
> Time: 305467.950 ms
> Time: 487133.179 ms
>
> Second run - on head:
>
> Time: 252218.609 ms
> Time: 234388.76
--- repost to hackers as suggested by RhodiumToad ---
hi,
i tried to test new "visibility map" feature.
to do so i:
1. fetched postgresql sources from cvs
2. compiled
3. turned autovacuum off
4. started pg
5. ran this queries:
- CREATE TABLE test_1 (i INT4);
- CREATE TABLE test_2 (i INT4);
Gregory Stark <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>
>> Gregory Stark wrote:
>>> 1) Raise autovacuum_max_freeze_age to 400M or 800M. Having it at 200M just
>>>means unnecessary full table vacuums long before they accomplish
>>> anything.
>>
>> It allows
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It just occurred to me that I think this circumvented the anti-wraparound
vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need to
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>
>>> Hmm. It just occurred to me that I think this circumvented the
>>> anti-wraparound
>>> vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need
>>> to
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It just occurred to me that I think this circumvented the anti-wraparound
vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need to
disable the skipping when autovacuum is triggered to prevent wraparou
Gregory Stark wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>
>> Hmm. It just occurred to me that I think this circumvented the
>> anti-wraparound
>> vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need
>> to
>> disable the skipping when autovacuum is triggered t
Heikki Linnakangas wrote:
> Hmm. It just occurred to me that I think this circumvented the
> anti-wraparound vacuuming: a normal vacuum doesn't advance relfrozenxid
> anymore. We'll need to disable the skipping when autovacuum is triggered
> to prevent wraparound. VACUUM FREEZE does that alr
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. It just occurred to me that I think this circumvented the anti-wraparound
> vacuuming: a normal vacuum doesn't advance relfrozenxid anymore. We'll need to
> disable the skipping when autovacuum is triggered to prevent wraparound.
> VACUUM
> FR
Heikki Linnakangas wrote:
Here's an updated version, with a lot of smaller cleanups, and using
relcache invalidation to notify other backends when the visibility map
fork is extended. I already committed the change to FSM to do the same.
I'm feeling quite satisfied to commit this patch early ne
Heikki Linnakangas wrote:
Here's an updated version, ...
And here it is, for real...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** src/backend/access/heap/Makefile
--- src/backend/access/heap/Makefile
***
*** 12,17 subdir = src/backend/access/heap
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
There is another problem, though, if the map is frequently probed for
pages that don't exist in the map, or the map doesn't exist at all.
Currently, the size of the map file is kept in relcache, in the
rd_vm_nblocks_cache variable.
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Well, considering how seldom new pages will be added to the visibility
map, it seems to me we could afford to send out a relcache inval event
when that happens. Then rd_vm_nblocks_cache could be treated as
trustwort
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, considering how seldom new pages will be added to the visibility
>> map, it seems to me we could afford to send out a relcache inval event
>> when that happens. Then rd_vm_nblocks_cache could be treated as
>> trustworthy.
>
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
There is another problem, though, if the map is frequently probed for
pages that don't exist in the map, or the map doesn't exist at all.
Currently, the size of the map file is kept in relcache, in the
rd_vm_nblocks_cache variable.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> There is another problem, though, if the map is frequently probed for
> pages that don't exist in the map, or the map doesn't exist at all.
> Currently, the size of the map file is kept in relcache, in the
> rd_vm_nblocks_cache variable. Whenever
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The visibility map won't be inquired unless you vacuum. This is a bit
tricky. In vacuum, we only know whether we can set a bit or not, after
we've acquired a cleanup lock on the page, and scanned all the tuples.
While we're holding
On Nov 23, 2008, at 3:18 PM, Tom Lane wrote:
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
visibility bits set.
That makes the idea of not writing out hint bit updates unless the
page is already dirty a l
Gregory Stark <[EMAIL PROTECTED]> writes:
> So if it's possible for the frozenxid in the visibility map to go backwards
> then it's no good, since if that update is lost we might skip a necessary
> vacuum freeze.
Seems like a lost disk write would be enough to make that happen.
Now you might argu
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> However I'm a bit puzzled how you could possibly maintain this frozenxid. As
>> soon as you freeze an xid you'll have to visit all the other pages covered by
>> that visibility map page to see what the new value should be.
>
Gregory Stark wrote:
However I'm a bit puzzled how you could possibly maintain this frozenxid. As
soon as you freeze an xid you'll have to visit all the other pages covered by
that visibility map page to see what the new value should be.
Right, you could only advance it when you scan all the pa
Tom Lane <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I've been thinking that we could add one frozenxid field to each
>> visibility map page, for the oldest xid on the heap pages covered by the
>> visibility map page. That would allow more fine-grained anti-wr
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So it seems like we do indeed want to rejigger autovac's rules a bit
>> to account for the possibility of wanting to apply vacuum to get
>> visibility bits set.
> I'm not too excited about triggering an extra vacuum. As Matthew po
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I've been thinking that we could add one frozenxid field to each
> visibility map page, for the oldest xid on the heap pages covered by the
> visibility map page. That would allow more fine-grained anti-wraparound
> vacuums as well.
This doesn't
Tom Lane wrote:
* ISTM that the patch is designed on the plan that the PD_ALL_VISIBLE
page header flag *must* be correct, but it's really okay if the backing
map bit *isn't* correct --- in particular we don't trust the map bit
when performing antiwraparound vacuums. This isn't well documented.
Tom Lane wrote:
Reflecting on it though, maybe Heikki described the behavior too
pessimistically anyway. If a page contains no dead tuples, it should
get its bits set on first visit anyhow, no? So for the ordinary bulk
load scenario where there are no failed insertions, the first vacuum
pass sh
Tom Lane wrote:
However, my comment above was too optimistic, because in an insert-only
scenario autovac would in fact not trigger VACUUM at all, only ANALYZE.
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
vi
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sun, 2008-11-23 at 14:05 -0500, Tom Lane wrote:
>> A possible problem is that if a relation is filled all in one shot,
>> autovacuum would trigger a single vacuum cycle on it and then never have
>> a reason to trigger another; leading to the bits never ge
On Sun, 2008-11-23 at 14:05 -0500, Tom Lane wrote:
> A possible problem is that if a relation is filled all in one shot,
> autovacuum would trigger a single vacuum cycle on it and then never have
> a reason to trigger another; leading to the bits never getting set (or
> at least not till an antiwra
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I committed the changes to FSM truncation yesterday, that helps with the
> truncation of the visibility map as well. Attached is an updated
> visibility map patch.
I looked over this patch a bit ...
> 1. The bits in the visibility map are set in
I committed the changes to FSM truncation yesterday, that helps with the
truncation of the visibility map as well. Attached is an updated
visibility map patch.
There's two open issues:
1. The bits in the visibility map are set in the 1st phase of lazy
vacuum. That works, but it means that aft
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The next question is whether the "pending rel deletion" stuff in smgr.c should
> be moved to the new file too. It seems like it would belong there better. That
> would leave smgr.c as a very thin wrapper around md.c
Well it's just a switch, albeit
Heikki Linnakangas wrote:
Another thing that does need to be fixed, is the way that the extension
and truncation of the visibility map is handled; that's broken in the
current patch. I started working on the patch a long time ago, before
the FSM rewrite was finished, and haven't gotten around f
On Tue, 2008-10-28 at 13:58 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> >> Lazy VACUUM only needs to visit pages that are '0' in the visibility
> >> map. This allows partial vacuums, where we only need to scan
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Yes, but there's a problem with recently inserted tuples:
> 1. A query begins in the slave, taking a snapshot with xmax = 100. So
> the effects of anything more recent should not be seen.
> 2. Transaction 100 inserts a tuple in the master, and comm
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
>> Lazy VACUUM only needs to visit pages that are '0' in the visibility
>> map. This allows partial vacuums, where we only need to scan those parts
>> of the table that need vacuuming, plus all
On Tue, 2008-10-28 at 19:02 +0200, Heikki Linnakangas wrote:
> Yes, but there's a problem with recently inserted tuples:
>
> 1. A query begins in the slave, taking a snapshot with xmax = 100. So
> the effects of anything more recent should not be seen.
> 2. Transaction 100 inserts a tuple in th
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> Lazy VACUUM only needs to visit pages that are '0' in the visibility
> map. This allows partial vacuums, where we only need to scan those parts
> of the table that need vacuuming, plus all indexes.
Just realised that this means we
Simon Riggs wrote:
On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
One option would be to just ignore that problem for now, and not
WAL-log.
Probably worth skipping for now, since it will cause patch
On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote:
> >> One option would be to just ignore that problem for now, and not
> >> WAL-log.
> >
> > Probably worth skipping for now, since it will cause patc
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
To modify a page:
If PD_ALL_VISIBLE flag is set, the bit in the visibility map is cleared
first. The heap page is kept pinned, but not locked, while the
visibility map is updated. We want to avoid holding a lock across I/O,
even t
Tom Lane wrote:
The harder part is propagating the bit to the visibility map, but I
gather you intend to only allow VACUUM to do that?
Yep.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
1 - 100 of 139 matches
Mail list logo
