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...
Re: Slow count(*) again... Re: Slow count(*) again... |
Список | 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 по дате отправления: