Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.databases.postgresql Subject: Re: migrating oracle to postgres Date: Thu, 23 Jun 2011 17:48:09 +0200 Lines: 44 Message-ID: <96h5hqFo39U1@mid.individual.net> References: <1308640710.210659@proxy.dienste.wien.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net mcnZxZm2E9emRXMVOT/bWwL6UZzgkiplF1JeBG0JmY/kdpXiY= Cancel-Lock: sha1:Vya0yxPswm/f2fiFusOq2m3/GUo= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.databases.postgresql:145 On 06/21/2011 03:38 PM, Mladen Gogala wrote: > On Tue, 21 Jun 2011 09:18:07 +0200, Laurenz Albe wrote: > >> PS: Don't let people discourage you. PostgreSQL is a good and stable >> database system. > > It is stable, no contest there. Is it good or not is a matter of opinion. Unfortunately people often forget that "good" in itself is meaningless and do not provide a list of criteria as you do. > I could list several grave faults which make it less than good in my eyes. > The first and foremost is, of course, the lack of hints. Postgres is the > only major database system which lacks hints. The second is ludicrous > need to "vacuum" database. Why do you consider this bad? I agree that it sounds silly at first sight that the user needs to take care of cleaning up deadwood in the database. On the other hand, on an Oracle instance you'll likely also have periodic jobs doing statistics updates which is what VACUUMing also does. Reducing the work a transaction has to do can be beneficial for the client, too. > The third is the fact that Postgres doesn't do > multi-block reads. Isn't this alleviated by the OS doing readahead on many platforms? > Fixed size archive logs (16M) would be the next issue. This can be changed during compilation though. But I agree, you'd rather want this to be tuneable at runtime - at least without recompiling the software. > The lack of shared pool makes it impossible to see the plan of the > statement being executed. And there is more. That's unfortunate. At least you can see SQL currently executed by querying pg_stat_activity. Kind regards robert