From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Hannu Krosing <hannu(at)skype(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Where is the decision about placement of new tuple made ? |
Date: | 2005-07-12 18:02:45 |
Message-ID: | 20050712180245.GU92165@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
If you're going to do this I would suggest keeping in mind that a
similar tactic could be used to help keep a table clustered (I think
there may even be a TODO on that). The basic idea there is to use the
clustering index to decide the best page to put a tuple on and try and
return that page (or one close to it) from the FSM.
On Tue, Jul 12, 2005 at 04:30:04PM +0300, Hannu Krosing wrote:
>
> Where in the source is the decision about the placement new tuple (on
> which page to put it) made ?
>
> I'd like to take a look at adding "gravity" to that decision, do that I
> can make postgres to decide to place new tuple (inserted or updated)
> near the beginning of file, in order to make it possible for ordinary
> (lazy) vacuum to shrink relations more often, initially controlled by
> GUC, maybe later by some other, more automatic hints, like % of empty
> pages.
>
> My current jedi mindtricks (seqscan + update pk=pk on last tuple until
> its page nr in ctid changes) for shrinking relations do work, but not as
> well as I'd like them to ;)
>
> --
> Hannu Krosing <hannu(at)skype(dot)net>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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?"
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2005-07-12 18:06:46 | Re: 4 pgcrypto regressions failures - 1 unsolved |
Previous Message | Andrew Dunstan | 2005-07-12 17:54:47 | multibyte regression tests |