Re: PERSISTANT PREPARE (another point of view)

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: PERSISTANT PREPARE (another point of view)
Дата
Msg-id dcc563d10807220028i3b594198m66c42f2128bb4b6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: Re: PERSISTANT PREPARE (another point of view)
Следующее
От: "Christian Kindler"
Дата:
Сообщение: How to Select a Tupl by Nearest Date