On 2014-08-26 22:04:03 -0400, Robert Haas wrote:
> That's all I see on a first-read through.
I think I fixed all of them. Thanks.
> There might be other
> issues, and I haven't checked through it in great detail for mundane
> bugs, but generally, I favor pressing on relatively rapidly toward a
>
On 8/27/14, 1:38 AM, Andres Freund wrote:
It occurs to me that it'd also be nice to have some
>stats available on how this is performing; perhaps a dtrace probe for
>whenever we overflow to the hash table, and one that shows maximum
>usage for a statement? (Presumably that's not much extra code o
Andres Freund wrote:
> On 2014-08-26 22:19:47 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > I would say that the issue most deserving of performance testing is your
> > sizing of the linear-search array --- it's not obvious that 8 is a good
> > size.
>
> It's about the size of a cacheline
On 2014-08-26 20:44:32 -0500, Jim Nasby wrote:
> These results look very encouraging, especially thinking about the
> cache impact.
Yep. I've seen PrivateRefCount array accesses prominently in the source
of cache misses in big servers.
> It occurs to me that it'd also be nice to have some
> stats
On 2014-08-26 22:04:03 -0400, Robert Haas wrote:
> On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund wrote:
> > Here's the next version of this patch.
>
> + *much never requried. So we keep a small array of reference counts
>
> Typo. But I think you could just drop the whole sentence about
On 2014-08-26 22:19:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The biggest concern previously were some benchmarks. I'm not entirely
> > sure where to get a good testcase for this that's not completely
> > artificial - most simpler testcases don't pin many buffers.
>
> FWIW, I think th
Andres Freund writes:
> The biggest concern previously were some benchmarks. I'm not entirely
> sure where to get a good testcase for this that's not completely
> artificial - most simpler testcases don't pin many buffers.
FWIW, I think that's by design; we don't ever want to pin more than one
bu
On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund wrote:
> Here's the next version of this patch.
+ *much never requried. So we keep a small array of reference counts
Typo. But I think you could just drop the whole sentence about how
things used to be, especially since it's recapitulated e
On 8/26/14, 6:52 PM, Andres Freund wrote:
On 2014-03-21 19:22:31 +0100, Andres Freund wrote:
>Hi,
>
>I've been annoyed at the amount of memory used by the backend local
>PrivateRefCount array for a couple of reasons:
>
>a) The performance impact of AtEOXact_Buffers() on Assert() enabled
>bui
Hi,
On 2014-03-21 19:22:31 +0100, Andres Freund wrote:
> Hi,
>
> I've been annoyed at the amount of memory used by the backend local
> PrivateRefCount array for a couple of reasons:
>
> a) The performance impact of AtEOXact_Buffers() on Assert() enabled
>builds is really, really annoying.
>
On 2014-06-22 19:31:34 +0100, Simon Riggs wrote:
> Yes, that's roughly how the SLRU code works also, so sounds good.
Heh. I rather see that as an argument for it sounding bad :)
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development,
On 22 June 2014 16:09, Andres Freund wrote:
>> So if we treat the fast array as a circular LRU, we get
>> * pinning a new buffer when array has an empty slot is O(1)
>> * pinning a new buffer when array is full causes us to move the LRU
>> into the hash table and then use that element
>> * unpinn
On 2014-06-22 12:38:04 +0100, Simon Riggs wrote:
> On 9 April 2014 15:09, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
> >>> An orthogonal issue I noted is that we never check for overflow in the ref
> >>> count itself. While I understand over
On 9 April 2014 15:09, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
>>> An orthogonal issue I noted is that we never check for overflow in the ref
>>> count itself. While I understand overflowing int32 counter will take a
>>> large number of pins
On 2014-04-09 10:26:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It's not unreasonable to argue that we just shouldn't optimize for
> > several pins held by the same backend for the same and always touch the
> > global count.
>
> NAK.
Note I didn't implement it because I wasn't too conv
Andres Freund writes:
> It's not unreasonable to argue that we just shouldn't optimize for
> several pins held by the same backend for the same and always touch the
> global count.
NAK. That would be a killer because of increased contention for buffer
headers. The code is full of places where a
On 2014-04-09 10:09:44 -0400, Tom Lane wrote:
> The resource managers are interesting to bring up in this context.
> That mechanism didn't exist when PrivateRefCount was invented.
> Is there a way we could lay off the work onto the resource managers?
> (I don't see one right at the moment, but I'm
Andres Freund writes:
> On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
>> An orthogonal issue I noted is that we never check for overflow in the ref
>> count itself. While I understand overflowing int32 counter will take a
>> large number of pins on the same buffer, it can still happen in the
On Wed, Apr 9, 2014 at 9:38 AM, Andres Freund wrote:
> On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
>> On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
>> > I've tried to reproduce problems around this (when I wrote this), but
>> > it's really hard to construct cases that need more than 8
On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
> > I've tried to reproduce problems around this (when I wrote this), but
> > it's really hard to construct cases that need more than 8 pins. I've
> > tested performance for those cases by simpl
On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
> I've tried to reproduce problems around this (when I wrote this), but
> it's really hard to construct cases that need more than 8 pins. I've
> tested performance for those cases by simply not using the array, and
> while the performance suffer
On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
> On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund wrote:
> > I've tried to reproduce problems around this (when I wrote this), but
> > it's really hard to construct cases that need more than 8 pins. I've
> > tested performance for those cases by sim
On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund wrote:
>
>
> I've tried to reproduce problems around this (when I wrote this), but
> it's really hard to construct cases that need more than 8 pins. I've
> tested performance for those cases by simply not using the array, and
> while the performance su
On 2014-04-09 08:22:15 -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs wrote:
> > We've got to the stage now that saving this much memory is essential,
> > so this patch is a must-have.
> >
> > The patch does all I would expect and no more, so approach and details
> > look
On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs wrote:
> We've got to the stage now that saving this much memory is essential,
> so this patch is a must-have.
>
> The patch does all I would expect and no more, so approach and details
> look good to me.
>
> Performance? Discussed many years ago, but I
On 2014-04-09 05:34:42 -0400, Simon Riggs wrote:
> On 21 March 2014 14:22, Andres Freund wrote:
>
> > That seems to work fairly well. On the few tests I could run on my
> > laptop - I've done this during a flight - it's a small performance win
> > in all cases I could test. While saving a fair am
On 21 March 2014 14:22, Andres Freund wrote:
> That seems to work fairly well. On the few tests I could run on my
> laptop - I've done this during a flight - it's a small performance win
> in all cases I could test. While saving a fair amount of memory.
We've got to the stage now that saving thi
Hi,
I've been annoyed at the amount of memory used by the backend local
PrivateRefCount array for a couple of reasons:
a) The performance impact of AtEOXact_Buffers() on Assert() enabled
builds is really, really annoying.
b) On larger nodes, the L1/2/3 cache impact of randomly accessing
sev
28 matches
Mail list logo
