From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | stuporg(at)erols(dot)com, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] What I'm working on |
Date: | 1998-08-24 03:52:41 |
Message-ID: | Pine.BSF.4.02.9808240052000.295-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 23 Aug 1998, Bruce Momjian wrote:
> > On Sun, 23 Aug 1998, Bruce Momjian wrote:
> >
> > > Yes, I guess you could have both. I just think the normal user is going
> > > to prefer the span stuff better, but you have a good point. If we had
> > > one, we could buy time getting the other.
> >
> > For whomever is implementing the row-span stuff, can something be
> > added that keeps track of number of rows that are spanned? ie. if most of
> > the rows are spanning the rows, then I would personally like to know that
> > so that I can look at dumping and reloading the data with a database set
> > to a higher blocksize...
> >
> > There *has* to be some overhead, performance wise, in the database
> > having to keep track of row-spanning, and being able to reduce that, IMHO,
> > is what I see being able to change the blocksize as doing...
>
> Makes sense, though vacuum would presumably make all the blocks
> contigious.
Still going to involve two read requests from the postmaster to
the operating system for those two rows...vs one if the tuple doesn't have
to span two blocks...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-08-24 04:09:21 | Re: [HACKERS] What I'm working on |
Previous Message | t-ishii | 1998-08-24 03:51:36 | minor problem with detecting int64 in configure |