Re: PERSISTANT PREPARE (another point of view) - Mailing list pgsql-sql

From Scott Marlowe
Subject Re: PERSISTANT PREPARE (another point of view)
Date
Msg-id dcc563d10807220028i3b594198m66c42f2128bb4b6@mail.gmail.com
Whole thread Raw
In response to Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-sql
On Tue, Jul 22, 2008 at 12:43 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2008/7/20 Milan Oparnica <milan.opa@gmail.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.


pgsql-sql by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: PERSISTANT PREPARE (another point of view)
Next
From: "Christian Kindler"
Date:
Subject: How to Select a Tupl by Nearest Date