Bruce Momjian wrote:
> Should we use large objects for this, and beef them up. Seems that
> would be a good way. I have considered putting them in a hash
> bucket/directory tree for faster access to lots of large objects.
>
> There is a lot to say about storing long tuples outside the tables
> because long tuples fill cache buffers and make short fields longer to
> access.
I thought to use a regular table. Of course, it will eat
buffers, but managing external files or even large objects
for it IMHO isn't that simple, if you take transaction
commit/abort and MVCC problematic into account too. And IMHO
this is something that must be covered, because I meant to
create a DATATYPE that can be used as a replacement for TEXT
if that's too small, so it must behave as a regular datatype,
without any restrictions WRT beeing able to rollback etc.
Using LO or external files would need much more testing, than
creating one other shadow table (plus an index for it) at
CREATE TABLE. This table would automatically have all the
concurrency, MVCC and visibility stuff stable. And it would
automatically split into multiple files if growing very
large, be vacuumed, ...
Let me do it this way for 7.0, and then lets collect some
feedback and own experience with it. For 8.0 we can discuss
again, if doing it the hard way would be worth the efford.
> We use 8K blocks because that is the base size for most file systems.
> When we fsync an 8k buffer, the assumption is that that buffer is
> written in a single write to the disk. Larger buffers would be spread
> over the disk, making a single fsync() impossible to be atomic, I think.
>
> Also, larger buffers take more cache space per buffer, makeing the
> buffer cache more corse holding fewer buffers.
Maybe something to play with a little.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
