On Wed, Sep 07, 2005 at 12:31:01AM -0500, Jim C. Nasby wrote: > On Tue, Sep 06, 2005 at 07:02:20PM -0400, Tom Lane wrote: > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > If the 4 header fields in question were just normalized out, wouldn't > > > all the semantics continue to work the same? All I'm envisioning is > > > replacing them in each tuple with a pointer (vis_id) to another > > > datastore that would be roughly equivalent to: > > > > > CREATE TABLE visibility ( > > > vis_id SERIAL, > > > xmin int, > > > xmax int, > > > cmin int, > > > cmax_xmax int > > > ) > > > > > Of course you wouldn't use an actual table to do this, but hopefully > > > this clarifies my idea.
> Well, like I said, I'm not envisioning using a table to store that info. > Since we'd be storing 4 fixed-length fields, you wouldn't need to > actually store vis_id per entry, just use the offset into the page. > Assuming you use one 'slot' to store the id of the first set, you could > store 511 tuples per page, which doesn't sound very bad. I think this could be done with our "SLRU" mechanism, just like pg_clog, pg_subtrans and pg_multixact do. Whether it's really a good idea or not, it's another story. The problem is that you would be creating new ones all the time, it would become a huge source of contention, and it would use a lot of memory. Anyway you are just moving the storage somewhere else -- instead of having 4 fields in the tuple itself, you have one field which points the same 4 fields elsewhere. I don't see how is that a win; it's actually worse because you have to do two lookups. (And actually you have just enlarged the storage requirements because you need to store the "vis_id" twice.) -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com "La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
