Re: [WIP] cache estimates, cache access cost

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <greg(at)2ndQuadrant(dot)com>,<stark(at)mit(dot)edu>
Cc: <cedric(dot)villemain(dot)debian(at)gmail(dot)com>,<robertmhaas(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] cache estimates, cache access cost
Date: 2011-06-19 22:15:07
Message-ID: 4DFE2E9B020000250003E8C9@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith wrote:

> I'm not too concerned about the specific case you warned about
> because I don't see how sequential scan vs. index costing will be
> any different on a fresh system than it is now.

I think the point is that if, on a fresh system, the first access to
a table is something which uses a tables scan -- like select count(*)
-- that all indexed access would then tend to be suppressed for that
table. After all, for each individual query, selfishly looking at
its own needs in isolation, it likely *would* be faster to use the
cached heap data.

I see two ways out of that -- one hard and one easy. One way would
be to somehow look at the impact on the cache of potential plans and
the resulting impact on overall throughput of the queries being run
with various cache contents. That's the hard one, in case anyone
wasn't clear. ;-) The other way would be to run some percentage of
the queries *without* considering current cache contents, so that the
cache can eventually adapt to the demands.

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-06-19 22:30:39 Re: pgbench--new transaction type
Previous Message Greg Smith 2011-06-19 21:32:42 Re: [WIP] cache estimates, cache access cost