Re: Slow count(*) again...

Поиск
Список
Период
Сортировка
От Jon Nelson
Тема Re: Slow count(*) again...
Дата
Msg-id AANLkTina3zfQ01UwPqps_hogvR-ge=ur9zHCSsxvKAm8@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Ответы Re: Slow count(*) again...  (Greg Smith <greg@2ndquadrant.com>)
Re: Slow count(*) again...  (Luca Tettamanti <kronos.it@gmail.com>)
Re: Slow count(*) again...  (Mladen Gogala <mgogala@vmsinfo.com>)
Список pgsql-performance
On Tue, Oct 12, 2010 at 7:27 AM, Mladen Gogala
<mladen.gogala@vmsinfo.com> wrote:
>
> So, the results weren't cached the first time around. The explanation is the
> fact that Oracle, as of the version 10.2.0, reads the table in the private
> process memory, not in the shared buffers.  This table alone is  35GB in
> size,  Oracle took 2 minutes 47 seconds to read it using the full table
> scan. If I do the same thing with PostgreSQL and a comparable table,
> Postgres is, in fact, faster:


Well, I didn't quite mean that - having no familiarity with Oracle I
don't know what the alter system statement does, but I was talking
specifically about the linux buffer and page cache. The easiest way to
drop the linux caches in one fell swoop is:

echo 3 > /proc/sys/vm/drop_caches

Is there a command to tell postgresql to drop/clear/reset it's buffer_cache?

Clearing/dropping both the system (Linux) and the DB caches is
important when doing benchmarks that involve I/O.



--
Jon

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Runtime dependency from size of a bytea field
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Slow count(*) again...