From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | abrams(at)philos(dot)umass(dot)edu |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] include/config.h FOLLOWUP |
Date: | 1998-01-05 04:14:49 |
Message-ID: | 34B05E39.64A9E3FF@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Integration wrote:
>
> ps. why not allow for larger tuples in general? Do we take a speed hit?
Using large blocks is bad for performance: by increasing block size
you automatically decrease number of blocks in shared buffer pool -
this is bad for index scans and in multi-user environment!
Just remember that Informix (and others) use 2K blocks.
(Actually, I would like to have smaller blocks, but postgres lives
over file system...)
As for having big tuples - someone said about multi-representation
feature of Illustra (automatically storing of big fields outside
of tuple itself - in blobs, large objects, ...): looks very nice.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-01-05 04:21:08 | Re: [HACKERS] include/config.h FOLLOWUP |
Previous Message | Vadim B. Mikheev | 1998-01-05 03:35:10 | Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c') |