Re: Big 7.1 open items - Mailing list pgsql-hackers
From | JanWieck@t-online.de (Jan Wieck) |
---|---|
Subject | Re: Big 7.1 open items |
Date | |
Msg-id | 200006161242.OAA15163@hot.jw.home Whole thread Raw |
In response to | Re: Big 7.1 open items (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Big 7.1 open items
Re: Big 7.1 open items Re: Big 7.1 open items |
List | pgsql-hackers |
Tom Lane wrote: > > It gets a little trickier if you want to be able to split > multi-gig tables across several tablespaces, though, since > you couldn't just append ".N" to the base table path in that > scenario. > > I'd be interested to know what sort of facilities Oracle > provides for managing huge tables... Oracle tablespaces are a collection of 1...n preallocated files. Each table then is bound to a tablespace and allocates extents (chunks) from those files. There are some per table attributes that control the extent sizes with default values coming from the tablespace. The initial extent size, the nextextent and the pctincrease. There is a hardcoded limit for the numberof extents a table can have at all. In Oracle7 it was 512 (or somewhat below - don't recall correct). Maybethat's gone with Oracle8, don't know. This storage concept has IMHO a couple of advatages over ours. The tablespace files are preallocated, so there will never be a change in block allocation during runtimeand that's the base for fdatasync() beeing sufficient at syncpoints. All what might be inaccurateafter a crash is the last modified time in the inode, and that's totally irrelevant for Oracle. The fsck will never fail, and anything is up to Oracle's recovery. The number of total tablespace files is limited to a value that ensures, that the backends can keep themall open all the time. It's hard to exceed that limit. A typical SAP installation with more than 20,000 tables/indices doesn't need more than 30 or 40 of them. It is perfectly prepared for raw devices, since a tablespace in a raw device installation is simplyan area of blocks on a disk. 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. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-hackers by date: