On 26.06.2011 23:49, Kevin Grittner wrote:
"Kevin Grittner" wrote:
"Kevin Grittner" wrote:
Heikki Linnakangas wrote:
BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
PredicateLockTuple() and CheckForSerializableConflictOut() calls
in the codepath for a lossy bitmap? In the non-lossy
"Kevin Grittner" wrote:
> "Kevin Grittner" wrote:
>> Heikki Linnakangas wrote:
>>> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
>>> PredicateLockTuple() and CheckForSerializableConflictOut() calls
>>> in the codepath for a lossy bitmap? In the non-lossy case,
>>> heap_hot_search_buffe
"Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
>> PredicateLockTuple() and CheckForSerializableConflictOut() calls
>> in the codepath for a lossy bitmap? In the non-lossy case,
>> heap_hot_search_buffer() takes care of it, but not i
On 25.06.2011 22:29, Kevin Grittner wrote:
In looking this over I noticed something else that doesn't seem quite
right. In heapam.c there are two places where the execution of
PredicateLockTuple() is conditioned not just on MVCC visibility, but
also on HeapKeyTest(). I think those calls should
Heikki Linnakangas wrote:
> BTW, isn't bitgetpage() in nodeBitmapHeapscan.c missing
> PredicateLockTuple() and CheckForSerializableConflictOut() calls in
> the codepath for a lossy bitmap? In the non-lossy case,
> heap_hot_search_buffer() takes care of it, but not in the lossy
> case.
I think
Dan Ports wrote:
> Note that this hadn't been a reasonable option until last week
> when we added the check for non-MVCC snapshots, since there are
> lots of things that use heap scans but SeqScan is the only
> (currently-existing) one we want to lock.
That is the sort of thing that I tended t
On Wed, Jun 22, 2011 at 12:07:04PM +0300, Heikki Linnakangas wrote:
> Hmm, I wonder if we should move this logic to heapam.c. The optimization
> to acquire a relation lock straight away should apply to all heap scans,
> not only those coming from ExecSeqScan. The distinction is academic at
> the
Heikki Linnakangas wrote:
> On 22.06.2011 17:28, Tom Lane wrote:
>> Why is the call in ExecSeqScan at all, and not in the node
>> startup function?
>
> It makes sense to delay it until the scan is actually started, so
> that you don't get unnecessary serialization failures if the scan
> is neve
On 22.06.2011 17:28, Tom Lane wrote:
Dan Ports writes:
I was looking at ExecSeqScan today and noticed that it invokes
PredicateLockRelation each time it's called, i.e. for each tuple
returned. Any reason we shouldn't skip that call if
rs_relpredicatelocked is already set, as in the attached pat
Tom Lane wrote:
> Why is the call in ExecSeqScan at all, and not in the node startup
> function?
Because when I asked about the placement of such calls in January of
2010 I didn't get any advice which suggested that, and this was a
place I was able to find which worked correctly. If there's a
Dan Ports writes:
> I was looking at ExecSeqScan today and noticed that it invokes
> PredicateLockRelation each time it's called, i.e. for each tuple
> returned. Any reason we shouldn't skip that call if
> rs_relpredicatelocked is already set, as in the attached patch?
Why is the call in ExecSeqS
On 22.06.2011 07:58, Dan Ports wrote:
I was looking at ExecSeqScan today and noticed that it invokes
PredicateLockRelation each time it's called, i.e. for each tuple
returned. Any reason we shouldn't skip that call if
rs_relpredicatelocked is already set, as in the attached patch?
That would sav
I was looking at ExecSeqScan today and noticed that it invokes
PredicateLockRelation each time it's called, i.e. for each tuple
returned. Any reason we shouldn't skip that call if
rs_relpredicatelocked is already set, as in the attached patch?
That would save us a bit of overhead, since checking t
13 matches
Mail list logo
