Обсуждение: 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) #