From: | "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Markus Schiltknecht" <markus(at)bluegap(dot)ch>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some ideas about Vacuum |
Date: | 2008-01-16 13:49:55 |
Message-ID: | 9362e74e0801160549k226ae2b8u57f449c2efc68800@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> I haven't been paying close attention to this thread, but there is a
> couple general issues with using the WAL for this kind of things. First
> of all, one extremely cool feature of PostgreSQL is that transaction
> size is not limited by WAL space, unlike on many other DBMSs. I think
> many of the proposed ideas of reading WAL would require us to keep all
> WAL available back to the beginning of the oldest running transaction.
Initially i thought this may be required. But the current idea is Vacuum is
going to maintain a DSM per relation and it will update it, once the WAL
segement is switched. so if the WAL logging is happening at segment 2, then
the first segment will be scanned to update the DSM.
>
> Another issue is that reading WAL is inherently not very scalable.
> There's only one WAL for the whole cluster, and it needs to be read
> sequentially, so it can easily become a bottleneck on large systems.
Let me try to understand what would become a problem here. We are going to
have only one process, which would open this WAL (one segment at a time) and
update the DSMs. The limitation would be that we should have completed
reading the log before the WAL segment round-up. What else do you think
would be the problem?
Thanks,
Gokul.
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2008-01-16 13:55:13 | Re: [HACKERS] Including Snapshot Info with Indexes |
Previous Message | Andrew Dunstan | 2008-01-16 13:32:12 | Re: Password policy |