The above could already happen in 8.4, where the visibility map was
introduced. The contention on the VM buffer would be just as bad whether you
hold the heap page lock at the same time or not. I have not heard any
complaints of contention on VM buffers.
--
Heikki Linnakangas
a) First
Hmm, you have a point. If 100 backends simultaneously write to 100
different pages, and all of those pages are all-visible, then it's
possible that they could end up fighting over the buffer content lock
on the visibility map page. But why would you expect that to matter?
In a heavily
On Sat, Aug 20, 2011 at 4:48 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
The above could already happen in 8.4, where the visibility map was
introduced. The contention on the VM buffer would be just as bad whether you
hold the heap page lock at the same time or not. I have not
On Sat, Aug 20, 2011 at 4:48 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
a) First of all, it(Visibility Map) should have definitely affected the
scalability of postgres in scenarios where in updates occur during a time
batch window. May be the increase in speed of vacuums negate
On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
by your argument, if WALInserLock is held for 't' seconds, you should
definitely be holding visibility map lock for more than time frame 't'.
Nope, that's not how it works. Perhaps you should read the code.
On Sat, Aug 20, 2011 at 5:06 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
By your argument, we can say that no-one will create a index with a function
like random(), time(), date(), broken operators etc. Its hard to imagine a
index in which a a user will only want to insert and never
Peter Eisentraut wrote:
On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote:
In fact, now that I think about it, setting the transaction snapshot
from a utility statement would be functionally useful because then you
could take locks beforehand.
Another issue is that in some client
Greg Stark wrote:
On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... and that would be a seriously bad API. ?There are not SUSET
restrictions on other resources such as work_mem. ?Why do we need
one for this?
I think a better analogy would be imposing a maximum
On 20 August 2011 15:34, Bruce Momjian br...@momjian.us wrote:
Actually, using UNION instead of UNION ALL does prevent some infinite
loops:
While that is worth pointing out, it cannot be recommended as a way of
preventing infinite recursion; after all, all 5 WITH RECURSIVE
examples in the docs
On Fri, 19 Aug 2011, Tom Lane wrote:
I might be reading too much into the mention of tbm_lossify, but
I wonder if the problem is repeated invocations of tbm_lossify()
as the bitmap gets larger. Maybe that function needs to be more
aggressive about how much information it deletes per call.
Sergey E. Koposov m...@sai.msu.ru writes:
Yes, it turns out that the problem was in lossify'ing the bitmap to
intensely.
Yeah, I had just been coming to the same conclusion. Your table has
about 134M pages, and if the planner estimate of 62M rows was right
(and there's no reason it shouldn't
On Sun, 7 Aug 2011 14:57:36 +0200 Wojciech Muła
wojciech_m...@poczta.onet.pl wrote:
Hi all, does anybody work on this TODO item?
http://wiki.postgresql.org/wiki/Todo#PL.2FpgSQL
I didn't find any related posting/bug report.
Hi, I've prepared simple patch, please review.
Since exact array
Congratulations, David Fetter - on his new arrival! It's a big day!
I think that you have switched gears here and are in this paragraph
talking about the 8.4-era visibility map changes rather than my recent
work. There is zero evidence that those changes caused any
performance problem. I've spent a large chunk of the last four months
looking for
On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
by your argument, if WALInserLock is held for 't' seconds, you should
definitely be holding visibility map lock for more than time frame 't'.
Nope, that's not how it works. Perhaps you should read the
By your argument, we can say that no-one will create a index with a
function
like random(), time(), date(), broken operators etc. Its hard to imagine
a
index in which a a user will only want to insert and never select on it.
The whole point of this optimization is to make index access
16 matches
Mail list logo
