Re: Big 7.1 open items

Bruce Momjian wrote:
> > There are also disadvantages.
> >
> > You can run out of space even if there are plenty GB's
> > free on your disks. You have to create tablespaces
> > explicitly.
> >
> > If you've choosen inadequate extent size parameters, you
> > end up with high fragmented tables (slowing down) or get
> > stuck with running against maxextents, where only a reorg
> > (export/import) helps.
>
> Also, Tom Lane pointed out to me that file system read-ahead does not
> help if your table is spread around in tablespaces.

Not with our HEAP concept. With the Oracle EXTENT concept it
does pretty good, because they have different block/extent
sizes. Usually an extent spans multiple blocks, so in the
case of sequential reads they read each extent of probably
hundreds of K sequential. And in the case of indexed reads,
they know the extent and offset of the tuple inside of the
extent, so they know the exact location of the record inside
the tablespace to read.

The big problem we allways had (why we need TOAST at all) is
that the logical blocksize (extent size) of a table is bound
to your physical blocksize used in the shared cache. This is
fixed so deeply in the heap storage architecture, that I'm
scared about it.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #