From: | Marty Scholes <marty(at)outputservices(dot)com> |
---|---|
To: | Olivier Sirven <osirven(at)elma(dot)fr> |
Cc: | herve(at)elma(dot)fr, pgsql-performance(at)postgresql(dot)org, Marty Scholes <marty(at)outputservices(dot)com> |
Subject: | Re: PostgreSQL clustering VS MySQL clustering |
Date: | 2005-01-31 15:24:55 |
Message-ID: | 41FE4DC7.7060903@outputservices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Tell me if I am wrong but it sounds to me like like
> an endless problem....
Agreed. Such it is with caching. After doing some informal
benchmarking with 8.0 under Solaris, I am convinced that our major choke
point is WAL synchronization, at least for applications with a high
commit rate.
We have noticed a substantial improvement in performance with 8.0 vs
7.4.6. All of the update/insert problems seem to have gone away, save
WAL syncing.
I may have to take back what I said about indexes.
Olivier Sirven wrote:
> Le Vendredi 21 Janvier 2005 19:18, Marty Scholes a écrit :
>
>>The indexes can be put on a RAM disk tablespace and that's the end of
>>index problems -- just make sure you have enough memory available. Also
>>make sure that the machine can restart correctly after a crash: the
>>tablespace is dropped and recreated, along with the indexes. This will
>>cause a machine restart to take some time.
>
> Tell me if I am wrong but it sounds to me like like an endless problem....This
> solution may work with small indexes (less than 4GB) but what appends when
> the indexes grow ? You would add more memory to your server ? But there will
> be a moment were you can not add more so what's next ?
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Chandler | 2005-01-31 17:19:18 | Performance degredation at client site |
Previous Message | Olivier Sirven | 2005-01-31 15:16:07 | Re: PostgreSQL clustering VS MySQL clustering |