Обсуждение: AW: [HACKERS] Problems with >2GB tables on Linux 2.0

    > and solving the data distribution as a separate effort.

I also think, that this issue can not be solved with splitting the table
extents
to different directories. I would leave that issue to a Tablespace
implementation.
What I like though is the idea that all table files have the extent number
in the 
filename, starting with tabname.1, and not having tabname (1. extent)
tabname.1
(2. extent).

Asside from that, I think anybody having a (non blob) table of 2-4 Gb and
above 
should start thinking of a redesign of his data model. Often the solution is
to have 
e.g. one table per year and a union all view, so that clients can access all
data
without even noticing. I think smart rewrite rules can be implemented, so
that updates,
inserts and deletes are routed to the correct table (let's call it
fragment).

Andreas

Zeugswetter Andreas IZ5 wrote:
> 
> Asside from that, I think anybody having a (non blob) table of 2-4 Gb and
> above should start thinking of a redesign of his data model. Often the 
> solution is to have e.g. one table per year and a union all view, so that
> clients can access all data without even noticing.

Oracle approaches this problem from the other end. In ver 8.x you can
define
virtual tables (or some name like that), which are actually views of
existing 
tables. These act mostly as ordinary tables - you can define indexes on
them,
insert/delet/update, views, etc. - except that the data is actually
stored in 
the main table.

> I think smart rewrite rules can be implemented, so that updates,
> inserts and deletes are routed to the correct table (let's call it
> fragment).

Probably, but why must one do that extra work which should be done by
the 
database (in an ideal world) ?

Oracles virtual tables are probably 'smart rewrite rules', just the user 
does not have to be too smart to use them.

----------------
Hannu

On Tue, 9 Feb 1999, Zeugswetter Andreas IZ5 wrote:

>     > and solving the data distribution as a separate effort.
> 
> I also think, that this issue can not be solved with splitting the
> table extents to different directories. I would leave that issue to a
> Tablespace implementation. What I like though is the idea that all
> table files have the extent number in the filename, starting with
> tabname.1, and not having tabname (1. extent) tabname.1 (2. extent).

This is something we need to thrash out here ;-)
> Asside from that, I think anybody having a (non blob) table of 2-4 Gb
> and above should start thinking of a redesign of his data model. Often
> the solution is to have e.g. one table per year and a union all view,
> so that clients can access all data without even noticing. I think
> smart rewrite rules can be implemented, so that updates, inserts and
> deletes are routed to the correct table (let's call it fragment).

The senario I can think of, is a database containing astronomical
observations (aka tass http://www.tass-survey.org)

You have one row per object, and this table is indexed against not just
the position of the object, but its observed photometric properties, etc.

It would be pretty difficult to maintain seeing what the expected volume
of data is going to be.

-- 
Peter Mount, IT Section
petermount@it.maidstone.gov.uk
Anything I write here are my own views, and cannot be taken as being the
official words of Maidstone Borough Council

Hannu Krossing wrote:
>
> Oracles virtual tables are probably 'smart rewrite rules', just the user
> does not have to be too smart to use them.

    Look  at our programmers manual and into the rules regression
    test.  The examples given there show, that the  functionality
    is already part of the Postgres rule system.

    Just the interface to setup the scenario isn't that easy.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #