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

2005-01-13 Thread Mark Kirkwood
Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: 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 long as the thing predicts exactly one row retrieved. So it's quasi-random which plan you

Re: [PERFORM] Performance delay

2005-01-13 Thread Richard Huxton
Hasnul Fadhly bin Hasan wrote: Hi, just want to share with all of you a wierd thing that i found when i tested it. i was doing a query that will call a function long2ip to convert bigint to ips. so the query looks something like this. select id, long2ip(srcip), long2ip(dstip) from sometable

Re: [PERFORM] Performance delay

2005-01-13 Thread Hasnul Fadhly bin Hasan
Hi Richard, Thanks for the reply.. is that the case? i thought it would comply to the where condition first.. and after that it will format the output to what we want.. Hasnul Richard Huxton wrote: Hasnul Fadhly bin Hasan wrote: Hi, just want to share with all of you a wierd thing that i found

[PERFORM] MOVE command

2005-01-13 Thread PFC
Hello, Here I'm implementing a session management, which has a connections table partitioned between active and archived connections. A connection represents a connection between a user and a chatroom. I use partitioning for performance reasons. The active table contains all the

Re: [PERFORM] Performance delay

2005-01-13 Thread Jim C. Nasby
On Thu, Jan 13, 2005 at 07:14:10PM +0800, Hasnul Fadhly bin Hasan wrote: Hi Richard, Thanks for the reply.. is that the case? i thought it would comply to the where condition first.. and after that it will format the output to what we want.. That is in fact exactly what it's doing. The

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

2005-01-13 Thread Alex Turner
This is somewhat correct, and somewhat unfair - bear in mind that Postgresql doesn't have the equivalent features of Oracle enterprise edition including RAC and Enterprise Manager. You can use Oracle Personal edition for development, or pay a per head cost of $149/user for your dev group for

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

2005-01-13 Thread Joe Conway
Alex Turner wrote: I'm not advocating that people switch to Oracle at all, It's still much more expensive than Postgresql, and for most small and medium applications Postgresql is much easier to manage and maintain. I would just like to make sure people get their facts straight. I worked for a

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

2005-01-13 Thread Tom Lane
Mark Kirkwood [EMAIL PROTECTED] writes: Hmmm ... so it's only the selectivity that is the same (sourced from index-amcostestimate which I am guessing points to btcostestimate), is that correct? No, the point is that btcostestimate will compute not only the same selectivities but the identical

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

2005-01-13 Thread William Yu
Gavin Sherry wrote: 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. The theshold for using PAE is actually far lower than 4GB. 4GB is the total memory

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

2005-01-13 Thread Joe Conway
Alex Turner wrote: I appreciate your information, but it's not valid. Most people don't need RAC or table partitioning. From a small company perspective, maybe, but not in the least invalid for larger companies. Many of the features in Oracle EE are just not available in Postgresql at all, and

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

2005-01-13 Thread Alex Turner
Joe, I appreciate your information, but it's not valid. Most people don't need RAC or table partitioning. Many of the features in Oracle EE are just not available in Postgresql at all, and many aren't available in any version of SQL Server (table partitioning, bitmap indexes and others). If you

[PERFORM] sum of all values

2005-01-13 Thread Madison Kelly
Hi all, Is there a fast(er) way to get the sum of all integer values for a certain condition over many thousands of rows? What I am currently doing is this (which takes ~5-10sec.): SELECT SUM (a.file_size) FROM file_info_1 a, file_set_1 b WHERE a.file_name=b.fs_name AND

Re: [ADMIN] [PERFORM] Assimilation of these versus and hardware

2005-01-13 Thread Matthew T. O'Connor
Josh Berkus wrote: Matt, I had one comment on the pg_autovacuum section. Near the bottom it lists some of it's limitations, and I want to clarify the 1st one: Does not reset the transaction counter. I assume this is talking about the xid wraparound problem? If so, then that bullet can be

[PERFORM] Best filesystem for PostgreSQL Database Cluster under Linux

2005-01-13 Thread Pete de Zwart
Greetings to one and all, I've been trying to find some information on selecting an optimal filesystem setup for a volume that will only contain a PostgreSQL Database Cluster under Linux. Searching through the mailing list archive showed some promising statistics on the various filesystems

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

2005-01-13 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 FC

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

2005-01-13 Thread Jan Dittmer
Joshua D. Drake wrote: RAID controllers tend to use i960 or StrongARM CPUs that run at speeds that _aren't_ all that impressive. With software RAID, you can take advantage of the _enormous_ increases in the speed of the main CPU. I don't know so much about FreeBSD's handling of this, but on

Re: [PERFORM] Best filesystem for PostgreSQL Database Cluster under Linux

2005-01-13 Thread Pete de Zwart
Thanks for the info. I managed to pull out some archived posts to this list from the PostgreSQL web site about this issue which have helped a bit. Unfortunatly, the FS has been chosen before considering the impact of it on I/O for PostgreSQL. As the Cluster is sitting on it's on 200GB IDE