Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-18 Thread Achilleas Mantzios
Thanx, Στις Monday 17 January 2011 18:52:27 ο/η Ing. Marcos Ortiz Valmaseda έγραψε: > > Well, on the Release Notes on the PostgreSQL-8.4 Documentation, the > developers recommend to use NOT EXISTS > instead NOT IN, because the first clause has a better performance. So, you > can use it on that

Re: [PERFORM] The good, old times

2011-01-18 Thread Devrim GÜNDÜZ
On Wed, 2011-01-12 at 08:49 -0500, Mladen Gogala wrote: > 7 kilobytes per second??? That brings back the times of the good, old > 9600 USR modems and floppy disks. The machine is serving 40-50 Mbit/sec, and 90% of its traffic is for pgrpms.org. I'm hosting the server in Turkey, and it is my ow

Re: [PERFORM] The good, old times

2011-01-18 Thread Dave Page
2011/1/18 Devrim GÜNDÜZ : > On Wed, 2011-01-12 at 08:49 -0500, Mladen Gogala wrote: > > >> 7 kilobytes per second???  That brings back the times of the good, old >> 9600 USR modems and floppy disks. > > The machine is serving 40-50 Mbit/sec, and 90% of its traffic is for > pgrpms.org. I'm hosting

Re: [PERFORM] Bad plan when join on function

2011-01-18 Thread Shaun Thomas
On 01/17/2011 02:03 AM, Zotov wrote: select c.id from OneRow c join abstract a on a.id=AsInteger(c.id) OneRow Contains only one row, abstract contains 22 953 500 rows AsInteger is simple function on Delphi it just return input value Ok... there has to be some kind of misunderstanding, here.

Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-18 Thread Mladen Gogala
Achilleas Mantzios wrote: Thanx, Στις Monday 17 January 2011 18:52:27 ο/η Ing. Marcos Ortiz Valmaseda έγραψε: Well, on the Release Notes on the PostgreSQL-8.4 Documentation, the developers recommend to use NOT EXISTS instead NOT IN, because the first clause has a better performance. So, you

[PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Lars
Hi, We are in the process of moving a web based application from a MySql to Postgresql database. Our main reason for moving to Postgresql is problems with MySql (MyISAM) table locking. We will buy a new set of servers to run the Postgresql databases. The current setup is five Dell PowerEdge 295

Re: [PERFORM] hashed subplan 5000x slower than two sequential operations

2011-01-18 Thread masterchief
> Tom Lane wrote: > > The only really effective way the planner knows to optimize an > "IN (sub-SELECT)" is to turn it into a semi-join, which is not possible > here because of the unrelated OR clause. You might consider replacing > this with a UNION of two scans of "contexts". (And yes, I know

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Andy Colson
On 1/18/2011 4:56 AM, Lars wrote: Hi, We are in the process of moving a web based application from a MySql to Postgresql database. Our main reason for moving to Postgresql is problems with MySql (MyISAM) table locking. We will buy a new set of servers to run the Postgresql databases. The curren

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Andy Colson
oops, call them database 'a' and database 'b'. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] hashed subplan 5000x slower than two sequential operations

2011-01-18 Thread Віталій Тимчишин
2011/1/18 masterchief > > > Tom Lane wrote: > > > > The only really effective way the planner knows to optimize an > > "IN (sub-SELECT)" is to turn it into a semi-join, which is not possible > > here because of the unrelated OR clause. You might consider replacing > > this with a UNION of two sc

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Strange, John W
Are you going to RAID the SSD drives at all? You would likely be better off with a couple of things. - increasing ram to 256GB on each server to cache most of the databases. (easy, and cheaper than SSD) - move to fusionIO - move to SLC based SSD, warning not many raid controllers will get the

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Mark Felder
On Tue, 18 Jan 2011 16:06:17 -0600, Strange, John W wrote: Of course this is based on my experience, and I have my fireproof suit since I mentioned the word fusionIO :) I'll throw a fire blanket up as well. We have a customer who has been running Fusion IO with Postgres for about 2 years

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread mark
Comments in line, take em for what you paid for em. > -Original Message- > From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] On Behalf Of Lars > Sent: Tuesday, January 18, 2011 3:57 AM > To: pgsql-performance@postgresql.org > Subject: [PERFOR

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Craig Ringer
On 18/01/11 18:56, Lars wrote: > Hi, > > We are in the process of moving a web based application from a MySql to > Postgresql database. > Our main reason for moving to Postgresql is problems with MySql (MyISAM) > table locking. > We will buy a new set of servers to run the Postgresql databases.

Re: [PERFORM] Migrating to Postgresql and new hardware

2011-01-18 Thread Scott Marlowe
On Tue, Jan 18, 2011 at 3:56 AM, Lars wrote: > Any comments on the setups? How would an alternative with 15K disks (6 RAID > 10 + 1 spare, or even 10 RAID10 + 1 spare) compare? RAID-10 is going to trounce RAID-5 for writes, which is where you usually have the most issues. > How would these alt