| From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | darrenk(at)insightdist(dot)com (Darren King) |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Block Sizes |
| Date: | 1998-01-06 15:18:18 |
| Message-ID: | 199801061518.KAA20766@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> >
> > How hard would it be for postgresql to support adjustable block sizes?
> > Just wondering.
> >
>
> I can take a stab at this tonite after work now that the snapshot is there.
> Still have around some of the files/diffs from looking at this a year ago...
>
> I don't think it will be hard, just a few files with BLCKSZ/MAXBLCKSZ
> references to check for breakage. Appears that only one bit of lp_flags is
> being used too, so that would seem to allow up to 32k blocks.
>
> Other issue is the bit alignment in the ItemIdData structure. In the past,
> I've read that bit operations were slower than int ops. Is this the case?
Usually, yes.
>
> I want to check to see if the structure is only 32 bits and not being padded
> by the compiler. Worse to worse, make one field of 32 bits and make macros
> to access the three pieces or make lp_off & lp_len shorts and lp_flags a char.
>
> I can check the aix compiler, but what does gcc and other compilers do with
> bit field alignment?
I don't know.
--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tony Rios | 1998-01-06 15:53:35 | Re: [HACKERS] database size |
| Previous Message | Bruce Momjian | 1998-01-06 15:13:01 | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results |