Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

2005-01-12 Thread Joe Conway
Greg Sabino Mullane wrote: Don't forget your support contract cost, as well as licenses for each of your servers: development, testing, QA, etc. Is it really as "cheap" as 5K? I've heard that for any fairly modern system, it's much more, but that may be wrong. Sort of -- see: http://oraclestore

Re: [PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Tom Lane
Mark Kirkwood <[EMAIL PROTECTED]> writes: > I happen to have some debugging code enabled for the optimizer, and the > issue appears to be that the costs of paths using these indexes are > quite similar, so are quite sensitive to (some) parameter values. They'll be exactly the same, actually, as lo

Re: [PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Mark Kirkwood
Ragnar HafstaĆ° wrote: it is not rational to have random_page_cost < 1. I agree, in theory one should never *need* to set it < 1. However in cases when the optimizers understanding of things is a little off, compensation may be required to achieve better plans (e.g. encouraging index scans on data

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

2005-01-12 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Oracle is not that expensive - standard one can be got for $149/user > or $5k/CPU, and for most applications, the features in standard one > are fine. Don't forget your support contract cost, as well as licenses for each of your servers: develo

Re: [PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Ragnar HafstaĆ°
On Thu, 2005-01-13 at 12:14 +1300, Mark Kirkwood wrote: [snip some explains] > > I have random_page_cost = 0.8 in my postgresql.conf. Setting it back to > the default (4) results in a plan using test_id1. it is not rational to have random_page_cost < 1. if you see improvement with such a setti

Re: [PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Mark Kirkwood
Litao Wu Wrote: explain analyze SELECT module, sum(action_deny) FROM test WHERE created >= ('now'::timestamptz - '1 day'::interval) AND customer_id='100' AND domain='100' GROUP BY module; Here is my output for this query: QUERY PLA

Re: [PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Mike Mascari
Litao Wu wrote: Hi All, Here is my test comparison between Postgres (7.3.2) optimizer vs Oracle (10g) optimizer. It seems to me that Postgres optimizer is not smart enough. Did I miss anything? Yeah, 7.4. 7.3.2 is *ancient*. Here's output from 7.4: [EMAIL PROTECTED] explain analyze test-# SELEC

[PERFORM] Postgres Optimizer is not smart enough?

2005-01-12 Thread Litao Wu
Hi All, Here is my test comparison between Postgres (7.3.2) optimizer vs Oracle (10g) optimizer. It seems to me that Postgres optimizer is not smart enough. Did I miss anything? Thanks, In Postgres: drop table test; create table test ( modulecharacter varying(50), acti

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

2005-01-12 Thread Alex Turner
No - I agree - Analysis cache hit rate as a single indicator is dangerous. You can easily increase cache hit rate by de-optimizing a good query so it uses more CPU cylces, and therefore has a higher cache hit rate. All information has to be taken as a whole when performing optimization on a syste

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

2005-01-12 Thread Greg Stark
Alex Turner <[EMAIL PROTECTED]> writes: > Infact the cache hit ratio that Oracle suggests is the minimum good > value is 95%. Anything below that is bad news. Well that seems very workload dependent. No amount of cache is going to be able to achieve that for a DSS system chugging sequentially

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

2005-01-12 Thread Alex Turner
Infact the cache hit ratio that Oracle suggests is the minimum good value is 95%. Anything below that is bad news. The reason is pretty obvious - RAM transfer speed is around 3.2G/sec these days, whilst even the best array isn't going to give more than 400MB/sec, and that's not even starting to t

Re: [PERFORM] Increasing RAM for more than 4 Gb. using postgresql

2005-01-12 Thread Martin Tedjawardhana
> Yes , of course I must try to upgrade PGsql to 7.4 and may be OS to FC 2-3 > too. > My server products are intel based [mainboard , CPU ,Case , Power supply ,RAID > Network card] dual Xeon 32 bit 3.0 Ghz which I consulted Thai intel supervisor > and they told me that increasing the ram for more

Re: [PERFORM] Increasing RAM for more than 4 Gb. using postgresql

2005-01-12 Thread amrit
> There is no problem with free Linux distros handling > 4 GB of memory. The > problem is that 32 hardware must make use of some less than efficient > mechanisms to be able to address the memory. > > So, try 7.4 before the memory upgrade. If you still have performance issues, > try optimising your

Re: [PERFORM] Increasing RAM for more than 4 Gb. using postgresql

2005-01-12 Thread Gavin Sherry
On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote: > I wonder if I would like to increase more RAM from 4 Gb. to 6 Gb. [which I > hope > to increase more performance ] and I now I used RH 9 and Pgsql 7.3.2 ON DUAL > Xeon 3.0 server thay has the limtation of 4 Gb. ram, I should use which OS > between F

Re: [PERFORM] Increasing RAM for more than 4 Gb. using postgresql

2005-01-12 Thread Martin Tedjawardhana
Is that 4GB limit a hardware limitation? If it is, then there is not much you can do except upgrading the server. If the server is capable of handling more than 4GB of ram then you can just upgrade the kernel and enable high memory support (up to 64GB of memory in kernel 2.6.9). There is no need to