Re: Frequent Update Project: Design Overview of HOT Updates

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Frequent Update Project: Design Overview of HOT Updates
Дата
Msg-id 2e78013d0611100722n675af139gea5dc6381efe5d10@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Frequent Update Project: Design Overview of HOT Updates  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Frequent Update Project: Design Overview of HOT Updates
Список pgsql-hackers

On 11/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 11/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (2) Isn't this full of race conditions?

> I agree, there  could be race  conditions. But IMO we can handle those.

Doubtless you can prevent races by introducing a bunch of additional
locking.  The question was really directed to how much concurrent
performance is left, once you get done locking it down.


I understand your point and I can clearly see a chance to improve upon the current
locking implementation in the prototype even though we are seeing a good performance
boost for 50 clients and 50 scaling factor with pgbench runs as mentioned by Nikhil.

Regards,
Pavan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gevik Babakhani
Дата:
Сообщение: Protocol specs
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Protocol specs