From: | Luca Tettamanti <kronos(dot)it(at)gmail(dot)com> |
---|---|
To: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | mladen(dot)gogala(at)vmsinfo(dot)com, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Slow count(*) again... |
Date: | 2010-10-12 13:19:52 |
Message-ID: | AANLkTimyeTQDh22tZUbzCy+KkdzWVv2aEX=5SJ3vhjv=@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Tue, Oct 12, 2010 at 3:07 PM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
> On Tue, Oct 12, 2010 at 7:27 AM, Mladen Gogala
> <mladen(dot)gogala(at)vmsinfo(dot)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
AFAIK this won't affect Oracle when using direct IO (which bypasses
the page cache).
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2010-10-12 13:20:14 | Re: Slow count(*) again... |
Previous Message | Greg Smith | 2010-10-12 13:18:34 | Re: Slow count(*) again... |
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2010-10-12 13:20:14 | Re: Slow count(*) again... |
Previous Message | Greg Smith | 2010-10-12 13:18:34 | Re: Slow count(*) again... |