Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!news2.euro.net!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!195.96.0.7.MISMATCH!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail From: "Laurenz Albe" Newsgroups: comp.databases.postgresql References: <1308640710.210659@proxy.dienste.wien.at><1308738638.232318@proxy.dienste.wien.at><1308911383.819034@proxy.dienste.wien.at><1309166263.561072@proxy.dienste.wien.at><1309250071.981133@proxy.dienste.wien.at><1309333854.777629@proxy.dienste.wien.at> Subject: Re: Is PostgreSQL good? Date: Thu, 30 Jun 2011 09:14:16 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Organization: dienste.wien.at ISP Message-ID: <1309418077.803206@proxy.dienste.wien.at> X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Lines: 28 NNTP-Posting-Host: 141.203.254.23 X-Trace: 1309418080 aconews.univie.ac.at 5640 141.203.254.23 X-Complaints-To: abuse@univie.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.databases.postgresql:164 Mladen Gogala wrote: >> #2 is an opinion. What should I answer? > > You should let me know whether you think that there are situations in > which hints are required and if not, why not? The designers of all other > major RDBMS systems seem to disagree here. I am not sure if there are situations where they are needed. So far, I have not felt the need in PostgreSQL. >> I agree with #3 as far that a database must offer tools for tuning. I >> have named some that PostgreSQL has. Query tuning is always a bit of an >> art, don't pretend that there's a step-by-step foolproof method in >> Oracle. I may look like that to you because you know it well. > > Actually, there is a foolproof method in Oracle. You see where the time > is spent and you address the problem. That is what the wait event > interface is all about. And it's by no means an art form. EXPLAIN ANALYZE will show me where the time is spent. The "address the problem" is the nontrivial point here, in PostgreSQL as well as in Oracle. PostgreSQL is lacking one problem addressing tool that Oracle provides, but that dows not imply that there are none. Yours, Laurenz Albe