On Thu, Jun 30, 2011 at 3:42 PM, Merlin Moncure wrote:
> On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas wrote:
>> On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
I think the basic problem is that the cache pages are so large. It's
hard to make them smaller because that increase
On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas wrote:
> On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
>>> I think the basic problem is that the cache pages are so large. It's
>>> hard to make them smaller because that increases the cost of accessing
>>> the cache, as you already noted,
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure wrote:
>> I think the basic problem is that the cache pages are so large. It's
>> hard to make them smaller because that increases the cost of accessing
>> the cache, as you already noted, but at the same time, making an
>> eviction decision on a c
On Wed, Jun 29, 2011 at 3:18 PM, Robert Haas wrote:
>> With the algorithm as coded, to fully flush the cache you'd have to
>> find a series of *unhinted* tuples distributed across minimum of four
>> 64k wide page ranges, with the number of tuples being over the 5%
>> noise floor. Furthermore, to
On Thu, Jun 30, 2011 at 12:31 AM, Jim Nasby wrote:
> Would it be reasonable to keep a second level cache that store individual
> XIDs instead of blocks? That would provide protection for XIDs that are
> extremely common but don't have a good fit with the pattern of XID ranges
> that we're cachi
On Jun 29, 2011, at 3:18 PM, Robert Haas wrote:
> To be clear, I don't really think it matters how sensitive the cache
> is to a *complete* flush. The question I want to ask is: how much
> does it take to knock ONE page out of cache? And what are the chances
> of that happening too frequently? I
On Wed, Jun 29, 2011 at 3:16 PM, Merlin Moncure wrote:
> I think it's a fair point to ask how often thrashing cases will truly
> come up where you don't have some other significant cost like i/o.
> Even when you do thrash, you are just falling back on stock postgres
> behaviors minus the maintenan
On Wed, Jun 29, 2011 at 11:11 AM, Robert Haas wrote:
> On Fri, May 13, 2011 at 3:48 PM, Merlin Moncure wrote:
>> what's changed:
>> *) as advertised, i'm no longer bothering to cache invalid bits. hint
>> bit i/o via rollbacked transactions is not a big deal IMNSHO, so they
>> will work as they
On Fri, May 13, 2011 at 3:48 PM, Merlin Moncure wrote:
> what's changed:
> *) as advertised, i'm no longer bothering to cache invalid bits. hint
> bit i/o via rollbacked transactions is not a big deal IMNSHO, so they
> will work as they have always done.
> *) all the tuple visibility routines are
what's changed:
*) as advertised, i'm no longer bothering to cache invalid bits. hint
bit i/o via rollbacked transactions is not a big deal IMNSHO, so they
will work as they have always done.
*) all the tuple visibility routines are now participating in the cache
*) xmax commit bits are now being
10 matches
Mail list logo
