Re: SPGist "triple parity" concept doesn't work

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

In response to

Responses

Browse pgsql-hackers by date

  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