From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jochem van Dieten <jochemd(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |
Date: | 2005-12-06 21:07:45 |
Message-ID: | 1133903265.3719.37.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ühel kenal päeval, T, 2005-12-06 kell 16:01, kirjutas Tom Lane:
> Hannu Krosing <hannu(at)skype(dot)net> writes:
> > 1) run a transaction repeatedly, trying to hit a point of no concurrent
> > transactions,
>
> In the sort of 24x7 environment that people are arguing this is needed
> for, it's entirely possible that that will *never* succeed.
My OLTP transactions are usually 5-50ms in length. common sense tells
me, that if I disallow new transactions for 100ms, I am more than likely
to have waited for all existing ones to have finished and can do my 1 ms
of "take snapshot + commit" and let all the waiting transactions to
commence.
If the database is running longer transactions, there can be a GUC to
adjust the time CUNCURRENT CREATE INDEX will wait. For example for
trx'es mostly in 0.5-2 sec range the wait could be set to 3 sec.
-------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-06 21:11:59 | Re: Weird Grant/Revoke/Usage behavior |
Previous Message | Tom Lane | 2005-12-06 21:01:57 | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing |