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