Re: Frequent Update Project: Design Overview of HOT Updates
| От | NikhilS |
|---|---|
| Тема | Re: Frequent Update Project: Design Overview of HOT Updates |
| Дата | |
| Msg-id | d3c4af540611101123p671025d2r72651e9a428b4ba5@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Frequent Update Project: Design Overview of HOT Updates ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
| Список | pgsql-hackers |
Hi,
Yes, we have done a number of runs with and without autovacuum with parameters like 50 clients, 50 scaling factor and 25000 transactions per client. 50 clients should introduce a decent amount of concurrency. The tps values observed with the HOT update patch (850 tps) were approximately 200+% better than PG82 sources (270).
On 11/10/06, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
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
Yes, we have done a number of runs with and without autovacuum with parameters like 50 clients, 50 scaling factor and 25000 transactions per client. 50 clients should introduce a decent amount of concurrency. The tps values observed with the HOT update patch (850 tps) were approximately 200+% better than PG82 sources (270).
Runs with 25 clients, 25 scaling factor and 25000 transactions produce similar percentage increases with the HOT update patch.
Regards,
Nikhils
В списке pgsql-hackers по дате отправления: