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 l
Anssi Kääriäinen 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), 'a', 2);
> insert in
Heikki Linnakangas 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
>> determine that this was a
Heikki Linnakangas 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 (pgsql-hackers@postgresql.org)
To
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 avoid
Heikki Linnakangas 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 (which I should
re-do after all th
Heikki Linnakangas 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 be
combined into coarser-grained lo
On 13.01.2011 02:01, Kevin Grittner wrote:
Anssi Kääriäinen 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
Anssi Kääriäinen 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 predicate lock held b
Anssi Kääriäinen 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
should specify READ ON
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 our
Anssi Kääriäinen 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 be broken when using
Anssi Kääriäinen 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(*) from test_t2;
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 ve
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 ve
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 http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo
16 matches
Mail list logo
