From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-hackers(at)postgreSQL(dot)org, hailong(dot)li(at)qunar(dot)com |
Subject: | Re: SPGist "triple parity" concept doesn't work |
Date: | 2013-06-10 16:20:45 |
Message-ID: | 24219.1370881245@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> Thoughts?
> Give me some time to play around it. Will think.
I experimented a bit with the idea of taking a heavyweight lock to
represent the right to alter an inner tuple. The results were pretty
grim: an spgist index build example went from 225 ms to 380 ms, and
a test case involving concurrent insertions (basically the complainant's
original example pgbench-ified) went from 5400 tps to 4300 tps.
I hadn't realized our heavyweight lock code was quite that expensive :-(
Anyway I now think that we might be better off with the other idea of
abandoning an insertion and retrying if we get a lock conflict. That
would at least not create any performance penalty for non-concurrent
scenarios; and even in concurrent cases, I suspect you'd have to be
rather unlucky to get penalties as bad as the heavyweight-lock solution
is showing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-06-10 17:01:29 | Re: JSON and unicode surrogate pairs |
Previous Message | Tom Lane | 2013-06-10 15:43:28 | Re: JSON and unicode surrogate pairs |