On Thu, Jun 30, 2011 at 3:42 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure mmonc...@gmail.com wrote:
I think the basic problem is that the cache pages are so large. It's
On Thu, Jun 30, 2011 at 12:31 AM, Jim Nasby j...@nasby.net 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
On Wed, Jun 29, 2011 at 3:18 PM, Robert Haas robertmh...@gmail.com 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.
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure mmonc...@gmail.com 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
On Thu, Jun 30, 2011 at 11:44 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 30, 2011 at 11:18 AM, Merlin Moncure mmonc...@gmail.com 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
On Fri, May 13, 2011 at 3:48 PM, Merlin Moncure mmonc...@gmail.com 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
On Wed, Jun 29, 2011 at 11:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 13, 2011 at 3:48 PM, Merlin Moncure mmonc...@gmail.com 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
On Wed, Jun 29, 2011 at 3:16 PM, Merlin Moncure mmonc...@gmail.com 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
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? It
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
