Just a small thought. If the file decision is preferred, then it might
be worth considering to create a file per tablespace.
Thanks,
Gokul.
On Nov 9, 2007 7:15 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-11-09 at 13:27 +, Heikki Linnakangas wrote:
> > Alvaro Herrera wrote:
> >
On Fri, 2007-11-09 at 13:27 +, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > One idea is to have the first FSM page be movable, and create it by
> > extending the table when as soon as it's first "needed" (this would be
> > the first vacuum that needs to record free space on the table).
Alvaro Herrera wrote:
One idea is to have the first FSM page be movable, and create it by
extending the table when as soon as it's first "needed" (this would be
the first vacuum that needs to record free space on the table). The
page number used is recorded in the relcache entry (and pg_class).
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Simon Riggs wrote:
>>> Presumably we would not store an FSM for small tables? On the basis that
>>> the purpose of the FSM is to save on pointless I/O there must be a size
>>> of table below which an FSM is just overhead.
>> Hmm, do you mean that
Heikki Linnakangas wrote:
> - We need a solution for the indexes as well. A separate file would fit
> nicely for them, though the contents would be different because for indexes
> we only care if a page is unused or not.
FWIW I think it's worth considering that we may be interested in keeping
c
On Fri, 2007-11-09 at 09:23 +, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Simon Riggs wrote:
> >> Presumably we would not store an FSM for small tables? On the basis that
> >> the purpose of the FSM is to save on pointless I/O there must be a size
> >> of table below which an FSM is
On Fri, 2007-11-09 at 09:39 +, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2007-11-08 at 23:04 +, Gregory Stark wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>
> >>> The pages might well be in cache, so the file location might well be
> >>> irrelevant from an I/O p
Simon Riggs wrote:
On Thu, 2007-11-08 at 21:50 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
Presumably we would not store an FSM for small tables? On the basis that
the purpose of the FSM is to save on pointless I/O there must be a size
of table below which an FSM is just overhead.
Hmm, do
Simon Riggs wrote:
On Thu, 2007-11-08 at 23:04 +, Gregory Stark wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
The pages might well be in cache, so the file location might well be
irrelevant from an I/O perspective. Maybe. The nth page solution allows
the FSM block to be easily located w
On Thu, 2007-11-08 at 21:50 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Presumably we would not store an FSM for small tables? On the basis that
> > the purpose of the FSM is to save on pointless I/O there must be a size
> > of table below which an FSM is just overhead.
>
> Hmm, do yo
Alvaro Herrera wrote:
Simon Riggs wrote:
Presumably we would not store an FSM for small tables? On the basis that
the purpose of the FSM is to save on pointless I/O there must be a size
of table below which an FSM is just overhead.
Hmm, do you mean that we would open and verify every page of a
On Thu, 2007-11-08 at 23:04 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > The pages might well be in cache, so the file location might well be
> > irrelevant from an I/O perspective. Maybe. The nth page solution allows
> > the FSM block to be easily located without
Simon Riggs wrote:
> Presumably we would not store an FSM for small tables? On the basis that
> the purpose of the FSM is to save on pointless I/O there must be a size
> of table below which an FSM is just overhead.
Hmm, do you mean that we would open and verify every page of a small
relation unt
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The pages might well be in cache, so the file location might well be
> irrelevant from an I/O perspective. Maybe. The nth page solution allows
> the FSM block to be easily located without any FSM index, so might well
> be faster. Separate files mean more
On Thu, 2007-11-08 at 15:24 +, Heikki Linnakangas wrote:
> I still feel the FSM should be in a file of it's own, rather than
> distributed on every nth heap page. It makes scanning it quicker,
> because it's sequential rather than random access, we're going to need
> a
> solution for indexes
I found a nice paper describing a few free space management algorithms:
M. L. McAuliffe, M. J. Carey and M. H. Solomon, Towards Effective and
Efficient Free Space Management, Proceedings of the ACM SIGMOD, Jun.
1996, pages 389--400. http://citeseer.ist.psu.edu/mcauliffe96towards.html
The basi
16 matches
Mail list logo
