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
ofthe 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
isbound 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@Yahoo.com #
