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 2014-08-26 22:19:47 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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.
On 2014-08-26 22:04:03 -0400, Robert Haas wrote:
On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund and...@2ndquadrant.com 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
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
Andres Freund wrote:
On 2014-08-26 22:19:47 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 or
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.
b) On
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
builds is
On Tue, Aug 26, 2014 at 7:52 PM, Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On 9 April 2014 15:09, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
On 2014-06-22 12:38:04 +0100, Simon Riggs wrote:
On 9 April 2014 15:09, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
On 22 June 2014 16:09, Andres Freund and...@2ndquadrant.com 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
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 21 March 2014 14:22, Andres Freund and...@2ndquadrant.com 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
On 2014-04-09 05:34:42 -0400, Simon Riggs wrote:
On 21 March 2014 14:22, Andres Freund and...@2ndquadrant.com 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
On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs si...@2ndquadrant.com 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
On 2014-04-09 08:22:15 -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund and...@2ndquadrant.comwrote:
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
On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund and...@2ndquadrant.comwrote:
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
On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund and...@2ndquadrant.com 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
On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund and...@2ndquadrant.com 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
On Wed, Apr 9, 2014 at 9:38 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund and...@2ndquadrant.com wrote:
I've tried to reproduce problems around this (when I wrote this), but
it's really hard to
Andres Freund and...@2ndquadrant.com 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
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 and...@2ndquadrant.com 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
On 2014-04-09 10:26:25 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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
28 matches
Mail list logo
