Re: [HACKERS] SSI patch version 8

2011-01-14 Thread Anssi Kääriäinen
On 01/14/2011 02:21 AM, Kevin Grittner wrote: I hope you have no objection to having the code you wrote included in the test suite which is part of the patch. Well, if you do, I'll pull it back out and invent something similar... ;-) No objection. - Anssi -- Sent via pgsql-hackers mailing

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Heikki Linnakangas
On 13.01.2011 02:01, Kevin Grittner wrote: Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: So, count(*) queries are more than twice as slow compared to the old serializable transaction isolation level. I got this down from more than twice the run time to running 33% longer through

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Kevin Grittner
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Pardon my ignorance, but where exactly is the extra overhead coming from? Searching for a predicate lock? Right. As each tuple is read we need to ensure that there is a predicate lock to cover it. Since finer-grained locks can

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Kevin Grittner
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: where exactly is the extra overhead coming from? Keep in mind that this is a sort of worst case scenario. The data is fully cached in shared memory and we're doing a sequential pass just counting the rows. In an earlier benchmark

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Heikki Linnakangas
On 13.01.2011 16:51, Kevin Grittner wrote: Right. As each tuple is read we need to ensure that there is a predicate lock to cover it. Since finer-grained locks can be combined into coarser-grained locks we need to start with the fine grained and move toward checking the coarser grains, to

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Kevin Grittner
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: That sounds simple enough. Add a boolean field to HeapScanDesc, rs_relpredicatelocked, and set it when you acquire the relation lock. I'll take a look at doing that. Thanks! -Kevin -- Sent via pgsql-hackers mailing list

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Kevin Grittner
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 13.01.2011 16:51, Kevin Grittner wrote: But we acquired a relation lock up front, when we determined that this would be a heap scan, so we could short-circuit this whole thing if within the heapgettup_pagemode function we could

Re: [HACKERS] SSI patch version 8

2011-01-13 Thread Kevin Grittner
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: I think I found a problem. This is using SSI v8. The table definition: create table test_t (id integer, val1 text, val2 integer); create index test_idx on test_t(id) where val2 = 1; insert into test_t (select generate_series(0, 1),

Re: [HACKERS] SSI patch version 8

2011-01-12 Thread Kevin Grittner
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: So, count(*) queries are more than twice as slow compared to the old serializable transaction isolation level. I've looked at this enough to know that I can do something about that, but wanted to point out that this is a good example of why you

Re: [HACKERS] SSI patch version 8

2011-01-12 Thread Kevin Grittner
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: So, count(*) queries are more than twice as slow compared to the old serializable transaction isolation level. I got this down from more than twice the run time to running 33% longer through remembering the last relation for which a search for a

Re: [HACKERS] SSI patch version 8

2011-01-11 Thread Anssi Kääriäinen
On 01/10/2011 06:03 PM, Kevin Grittner wrote: Due to popular request (Hey, David's popular, right?), I'm posting a patch for Serializable Snapshot Isolation (SSI), although I don't yet have everything in it that I was planning on submitting before the CF. I will probably be submitting another

Re: [HACKERS] SSI patch version 8

2011-01-11 Thread Anssi Kääriäinen
On 01/10/2011 06:03 PM, Kevin Grittner wrote: Due to popular request (Hey, David's popular, right?), I'm posting a patch for Serializable Snapshot Isolation (SSI), although I don't yet have everything in it that I was planning on submitting before the CF. I will probably be submitting another

Re: [HACKERS] SSI patch version 8

2011-01-11 Thread Kevin Grittner
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: A speed test showing a significant drop in performance when using SSI: hot2= create table test_t2 as (select generate_series(0, 100)); hot2= \timing begin transaction isolation level repeatable read; Time: 0.185 ms hot2= select count(*)

Re: [HACKERS] SSI patch version 8

2011-01-11 Thread Kevin Grittner
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote: I think I found a problem. This is using SSI v8. Thanks much for testing. You're managing to exercise some code paths I didn't think to test, which is great! I guess this is the up side of having posted yesterday. :-) So, something seems to

Re: [HACKERS] SSI patch version 8

2011-01-11 Thread Anssi Kääriäinen
On 01/11/2011 04:53 PM, Kevin Grittner wrote: Thanks much for testing. You're managing to exercise some code paths I didn't think to test, which is great! I guess this is the up side of having posted yesterday. :-) Glad that I can help. This feature is something that is very important to

Re: [HACKERS] SSI patch version 8

2011-01-10 Thread David Fetter
On Mon, Jan 10, 2011 at 10:03:18AM -0600, Kevin Grittner wrote: Due to popular request (Hey, David's popular, right?), Well, I'm a person, and popular originally refers to something like that ;) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: