|
|
 | | From: | Greg Stark | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | 22 Jan 2005 12:20:53 -0500 |
|
|
 | Dawid Kuroczko writes:
> Quick thought -- would it be to possible to implement a 'partial VACUUM'
> per analogiam to partial indexes?
No.
But it gave me another idea. Perhaps equally infeasible, but I don't see why.
What if there were a map of modified pages. So every time any tuple was marked
deleted it could be marked in the map as modified. VACUUM would only have to
look at these pages. And if it could mark as free every tuple that was marked
as deleted then it could unmark the page.
The only downside I see is that this could be a source of contention on
multi-processor machines running lots of concurrent update/deletes.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
| | From: | Jim C. Nasby | | Subject: | Re: PostgreSQL clustering VS MySQL clustering | | Date: | Sat, 22 Jan 2005 14:10:49 -0600 |
|
|
| From http://developer.postgresql.org/todo.php:
Maintain a map of recently-expired rows
This allows vacuum to reclaim free space without requiring a sequential
scan
On Sat, Jan 22, 2005 at 12:20:53PM -0500, Greg Stark wrote:
> Dawid Kuroczko writes:
>
> > Quick thought -- would it be to possible to implement a 'partial VACUUM'
> > per analogiam to partial indexes?
>
> No.
>
> But it gave me another idea. Perhaps equally infeasible, but I don't see why.
>
> What if there were a map of modified pages. So every time any tuple was marked
> deleted it could be marked in the map as modified. VACUUM would only have to
> look at these pages. And if it could mark as free every tuple that was marked
> as deleted then it could unmark the page.
>
> The only downside I see is that this could be a source of contention on
> multi-processor machines running lots of concurrent update/deletes.
>
> --
> greg
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
|
|
| | From: | Christopher Browne | | Subject: | Cheaper VACUUMing | | Date: | Sun, 23 Jan 2005 01:16:20 -0500 |
|
|
| A long time ago, in a galaxy far, far away, gsstark@mit.edu (Greg Stark) wrote:
> Dawid Kuroczko writes:
>
>> Quick thought -- would it be to possible to implement a 'partial VACUUM'
>> per analogiam to partial indexes?
>
> No.
>
> But it gave me another idea. Perhaps equally infeasible, but I don't see why.
>
> What if there were a map of modified pages. So every time any tuple
> was marked deleted it could be marked in the map as modified. VACUUM
> would only have to look at these pages. And if it could mark as free
> every tuple that was marked as deleted then it could unmark the
> page.
>
> The only downside I see is that this could be a source of contention
> on multi-processor machines running lots of concurrent
> update/deletes.
I was thinking the same thing after hearing fairly extensive
"pooh-poohing" of the notion of vacuuming based on all the pages in
the shared cache.
This "hot list page table" would probably need to be a hash table. It
rather parallels the FSM, including the way that it would need to be
limited in size.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://cbbrowne.com/info/lsf.html
Rules of the Evil Overlord #57. "Before employing any captured
artifacts or machinery, I will carefully read the owner's manual."
|
|
| | From: | Jim C. Nasby | | Subject: | Re: Cheaper VACUUMing | | Date: | Sun, 23 Jan 2005 16:18:38 -0600 |
|
|
| For reference, here's the discussion about this that took place on
hackers: http://lnk.nu/archives.postgresql.org/142.php
On Sun, Jan 23, 2005 at 01:16:20AM -0500, Christopher Browne wrote:
> A long time ago, in a galaxy far, far away, gsstark@mit.edu (Greg Stark) wrote:
> > Dawid Kuroczko writes:
> >
> >> Quick thought -- would it be to possible to implement a 'partial VACUUM'
> >> per analogiam to partial indexes?
> >
> > No.
> >
> > But it gave me another idea. Perhaps equally infeasible, but I don't see why.
> >
> > What if there were a map of modified pages. So every time any tuple
> > was marked deleted it could be marked in the map as modified. VACUUM
> > would only have to look at these pages. And if it could mark as free
> > every tuple that was marked as deleted then it could unmark the
> > page.
> >
> > The only downside I see is that this could be a source of contention
> > on multi-processor machines running lots of concurrent
> > update/deletes.
>
> I was thinking the same thing after hearing fairly extensive
> "pooh-poohing" of the notion of vacuuming based on all the pages in
> the shared cache.
>
> This "hot list page table" would probably need to be a hash table. It
> rather parallels the FSM, including the way that it would need to be
> limited in size.
> --
> wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
> http://cbbrowne.com/info/lsf.html
> Rules of the Evil Overlord #57. "Before employing any captured
> artifacts or machinery, I will carefully read the owner's manual."
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
|
|
|
