Greg Stark wrote:
> Well we disagree with whether we have any reasonable plan for
> adding the more fine-grained locks.
We probably agree on that, too. Perhaps it's that I think we can
develop one within a few months and you don't?
> AFAICT we have either a) add something clean and abstract
On Fri, Jan 8, 2010 at 5:13 PM, Kevin Grittner
wrote:
>> From what I understand your first cut will just take full-table
>> "locks" anyways so it won't matter what type of plan is used at
>> all.
>
> Right. And it would be totally premature to try to test any
> optimizations at that phase, which
Greg Stark wrote:
> My comment was in relation to the idea of representing the costs
> in the planner. I was a) saying you had to see how the
> implementation went before you try to come up with how to
> represent the costs and then b) speculating (hypocritically:) that
> you might have the dire
On Thu, Jan 7, 2010 at 9:28 PM, Kevin Grittner
wrote:
> All valid points. I could try to make counter-arguments, but in my
> view the only thing that really matters is how any such attempt
> performs in a realistic workload. If, when we get to the
> optimization phase, such a technique shows a p
Greg Stark wrote:
> On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner
> wrote:
>> No, it's an attempt to reflect the difference in costs for true
>> serializable transactions, so that the optimizer can choose a
>> plan appropriate for that mode, versus some other. In
>> serializable transaction iso
On Thu, Jan 7, 2010 at 8:43 PM, Kevin Grittner
wrote:
> No, it's an attempt to reflect the difference in costs for true
> serializable transactions, so that the optimizer can choose a plan
> appropriate for that mode, versus some other. In serializable
> transaction isolation there is a higher co
Robert Haas wrote:
> thinking that fudging the tuple cost GUCs is going to work seems
> unrealistically optimistic. If you need the optimizer to know
> about this, you need the optimizer to REALLY know about this...
I rule nothing out. If you have a more refined idea, I welcome you
to includ
On Thu, Jan 7, 2010 at 3:43 PM, Kevin Grittner
wrote:
> "Albe Laurenz" wrote:
>> Kevin Grittner wrote:
>>> Another interesting thing which crossed my mind (and I should
>>> probably add a section for such things in the wiki) is that,
>>> given the overhead and conflict implications of using table
"Albe Laurenz" wrote:
> Kevin Grittner wrote:
>> Another interesting thing which crossed my mind (and I should
>> probably add a section for such things in the wiki) is that,
>> given the overhead and conflict implications of using table scans
>> in serializable transactions, we should perhaps try
Jeff Davis wrote:
> [discussion of a "pure" predicate locking scheme where each
> database modification is checked against a list of predicate
> expressions]
> My biggest worry is that a predicate locking scheme like this will
> be fairly difficult to implement and expensive to execute.
I co
On Thu, 2010-01-07 at 10:57 +0100, Albe Laurenz wrote:
> That sounds like major AI to me.
> What do you do if the condition involves user defined functions?
I don't see how it has anything to do with "user-defined" or not.
If the predicate is pure (immutable), it's no problem (regardless of
wheth
2010/1/7 Albe Laurenz :
> Nicolas Barbier wrote:
>
>> In such a pure implementation of predicate locking, the overlap
>> testing is be done using the algebraic properties of the conditions,
>> which is of course extremely difficult (if not impossible) to
>> implement perfectly in a system that all
Nicolas Barbier wrote:
>> I don't know if such a thing would be easy to implement in
>> PostgreSQL, but I had thought that the "standard" approach to
>> implement predicate locking is like this:
>>
>> Whenever you touch (read) a data structure, you tag it with a lock
>> that prevents anybody else f
2010/1/7 Albe Laurenz :
> I don't know if such a thing would be easy to implement in
> PostgreSQL, but I had thought that the "standard" approach to
> implement predicate locking is like this:
>
> Whenever you touch (read) a data structure, you tag it with a lock
> that prevents anybody else from
Robert Haas wrote:
> Jeff Davis wrote:
> > I have a question regarding true serializability and predicate locking.
> > There's some context on the wiki page:
> >
> > If you have the following DDL:
> >
> > create table mytable(mycircle circle);
> > create index mytable_mycircle_idx on mytable
> >
Kevin Grittner wrote:
> Another interesting thing which crossed my mind (and I should
> probably add a section for such things in the wiki) is that, given
> the overhead and conflict implications of using table scans in
> serializable transactions, we should perhaps try to discourage table
> scans
Jeff Davis wrote:
> Is a full table lock acceptable in the end? If so, then predicate
> locking is just optimization, and we should leave it until later.
I think that the predicate locking will need to be RAM-based to
provide acceptable performance, and that we will need a
multi-granularity ap
On Tue, 2010-01-05 at 13:47 -0600, Kevin Grittner wrote:
> I will not
> spend any significant amount of time looking at the specifics of any
> particular optimizations yet, because such premature optimization is
> certain to kill the whole project.
I'm certainly not trying to derail the project, I
Jeff Davis wrote:
> Clearly one of those transactions should abort, because that will
> happen in either serialized order. But I don't see where any lock
> is stored, nor how the conflict is detected.
That depends on where in the development cycle of this feature you
are. I'm anticipating tha
On Tue, Jan 5, 2010 at 2:14 PM, Jeff Davis wrote:
> I have a question regarding true serializability and predicate locking.
> There's some context on the wiki page:
>
> http://wiki.postgresql.org/wiki/Serializable
>
> under the heading "Predicate Locking".
>
> If you have the following DDL:
>
> c
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
http://wiki.postgresql.org/wiki/Serializable
under the heading "Predicate Locking".
If you have the following DDL:
create table mytable(mycircle circle);
create index mytable_myci
21 matches
Mail list logo
