> 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
> 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 u
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
On Sat, Aug 20, 2011 at 4:48 AM, Gokulakannan Somasundaram
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 that effect.
I thi
On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
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.
See, e.g., heap_upd
On Sat, Aug 20, 2011 at 5:06 AM, Gokulakannan Somasundaram
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 select on it.
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 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 number of rows
On 20 August 2011 15:34, Bruce Momjian 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 use UNION ALL.
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.
Thank
"Sergey E. Koposov" 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 be pretty cl
On Sun, 7 Aug 2011 14:57:36 +0200 Wojciech Muła
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 defintion isn't needed anyw
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 scala
On Sat, Aug 20, 2011 at 4:57 AM, Gokulakannan Somasundaram
> 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.
> See, e.
> > 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
CreateExtension() possibly creates a new schema when the supplied
extension was not relocatable and the target schema was given by
control file of the extension.
However, it allows users to create a new schema with his ownership,
even if current user does not have permission to create a new schema.
17 matches
Mail list logo
