| From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | milan(dot)opa(at)gmail(dot)com, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: PERSISTANT PREPARE (another point of view) |
| Date: | 2008-07-22 07:28:51 |
| Message-ID: | dcc563d10807220028i3b594198m66c42f2128bb4b6@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Tue, Jul 22, 2008 at 12:43 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2008/7/20 Milan Oparnica <milan(dot)opa(at)gmail(dot)com>:
>> Is it solved in MySQL or they've just tried ?
>
> http://www.mysqlperformanceblog.com/2006/08/02/mysql-prepared-statements/
Wow, the discussion at the bottom of that page made me really think.
In MySQL you rely on the statement cache to provide data really fast
without worrying too much about transactional semantics. In
PostgreSQL you set up a set of 1 or more slony machines to act as
cache / increase parallel performance. Or just throw more CPU and
memory at it along with memcached. Or both.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Kindler | 2008-07-22 08:42:56 | How to Select a Tupl by Nearest Date |
| Previous Message | Pavel Stehule | 2008-07-22 06:43:41 | Re: PERSISTANT PREPARE (another point of view) |