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
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
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
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
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
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
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
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),
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
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
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
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
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(*)
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
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
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:
16 matches
Mail list logo
