Re: [WIP] cache estimates, cache access cost

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [WIP] cache estimates, cache access cost
Дата
Msg-id 4DFE2E9B020000250003E8C9@gw.wicourts.gov
обсуждение исходный текст
Ответ на [WIP] cache estimates, cache access cost  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Ответы Re: [WIP] cache estimates, cache access cost  (Greg Smith <greg@2ndQuadrant.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: [WIP] cache estimates, cache access cost
Следующее
От: Greg Smith
Дата:
Сообщение: Re: pgbench--new transaction type