Re: [HACKERS] My 2c on adjustable blocksizes

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: abrams(at)philos(dot)umass(dot)edu
Cc: hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] My 2c on adjustable blocksizes
Date: 1998-01-06 04:43:26
Message-ID: 34B1B66E.97F90475@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I would like to stand up as being very much in favor of two related things:
>
> (1) adjustable blocksizes
> (2) a larger MAX TUPLE size
>
> As far as I can tell (and that ain't far), there would only be relatively
> minor changes that would have to be made to give the option of allowing
> the user to select 2, 4, 8 or 16 as the blocksize. Concurrently, it
> would seem wise to simply up the max tuple size to 32k. It seems to me
> unlikely that this would have a noticeable performance impact. In order
> to do this, we would need to know about the 32 bit ItemIdData structure in
> /storage/itemid.h (see my previous posts). It was recommended to me that
> lp_flags might still be only using 2 of the 6 bits allocated to it. If
> so, increasing lp_offset to 15 and lp_len to 15, i.e. 2^15 bits, i.e.
> 32768 bytes max tuple size, would be possible! I think!

If someone came up with some clean patches to allow #define declarations for
block size and for tuple sizes, I'm sure they would be of interest. The
ongoing work being discussed for v6.3 would not conflict with those areas (I
suspect) so go to it!

I have noticed some integer constants scattered around the code (in places
where they don't belong) which are related to a maximum tuple size. For
example, there is an arbitrary 4096 byte limit on the size of a character
column, and the 4096 is hardcoded into the parser. That particular one would
be easy to change...

- Tom

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-01-06 04:50:12 Re: [HACKERS] subselect
Previous Message Thomas G. Lockhart 1998-01-06 04:36:06 Re: [HACKERS] Postgres acl