Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux] - Mailing list pgsql-general
From | The Web Administrator |
---|---|
Subject | Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux] |
Date | |
Msg-id | 35B8BE25.C290B296@wizard.ca Whole thread Raw |
In response to | Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux] (Herve Lefebvre <aegir@rocketmail.com>) |
Responses |
Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]
|
List | pgsql-general |
Herve Lefebvre wrote: > ---Marc Fournier <marc.fournier@acadiau.ca> wrote: > > > > On Thu, 23 Jul 1998, The Web Administrator wrote: > > > > > Nope.. Oracle has a background process which re-allocates free > space..It does get > > > fragmented, and the only real way to unfrag is to export (dump) > and import.No Vacuum, > > > at least on 7.3.2 > > > > So, essentially, our VACUUM command provides functionality that > > Oracle *doesn't* have, right? > > I don't think any fragmentation occurs under Oracle, if dataspaces are > allocated on raw-devices (wich is a functionnality PG doesn't have). > Of course, most DBA's I know never use raw devices, because of issues such as backups, etc... and even then, (but I am no expert here) I understand that data still gets fragmented because of it's implementation of data blocks, and it's rules for when to use the next block etc.. It has to allow for records which expand and contract, so it leaves room initially to allow for this so that records never span across two data blocks etc..Getting out my trusty Oracle Manual.... Under Fragmentation.... To determine the amount of fragmentation... select tablespace_name, sum(bytes), max(bytes), count(tablespace_name) from dba_free_space group by tablespace_name order by tablespace_name / If the number of contigous blocks is greater than 10 to 15, you should defrag the tablespace. The steps are 1) export data from the tablespace with the 'exp' utility. For indexes, capture the SQL to recreate them 2) Drop all the objects 3) Drop the tablespace 4) Recreate the tablespace 5) Import the data back into the tablespace with the 'imp' utility. Maunally recreate indexes by using their SQL scripts. Having sorted all that out... I think we should stop asking what 'Others' have, and just concentrate on making Postgres the best database out there, and let 'Others' implement Postgres Features.. IMHO, to often we are so intent on copying the 'Big Guys' that qwe forget out own strengths to the point that we start burdening clean code with garbage for compatibilities sake, rather than looking at it from scratch and seeing what the most effecient method is... The boys at Postgres have so far done a good job of creating an effecient Database, let's keep it that way, rather than created a Clone of some commercial software that might have years of compatibility issues that forced implementation of methods that may not be the most effecient.. So let's stop comparing Postgres to the rest.. If there is something we need to do with our Databases that we can't, then these are the issues we should address only.. It's like saying let's unix should use back slashes instead of forward slashes.. just because that is what windows/dos does... Or that we should recode Ultima to use a Doom perspective... Let Postgres stand on it's own merits, and not it's Oracle Compatibility.. Imagine what would have happened if Linus Torvald whould have decided that Linux needed to be Windows compatible.. The code would not have been the work of art it is today.. Well enough editorializing.. That's my last note on the Postgres vs. the rest argument.. -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Michael - System Administrator Working in Cheap Canadian Dollars Unix Administration - WebSite Hosting - Network Services - Programming Wizard Internet Services - TechnoWizard Computers - Wizard Tower TechnoServices ------------------------------------------------------------------------------ (604) 589-0037 Beautiful British Columbia, Canada ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
pgsql-general by date: