From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: david@lang.hm <david@lang.hm>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: Vitalii Tymchyshyn <tivv00@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Slow count(*) again...
Date: Tue, 12 Oct 2010 10:04:18 -0400
Message-ID: <4CB46AE2.7030006@vmsinfo.com> (raw)
In-Reply-To: <23516.1286891790@sss.pgh.pa.us>
References: <201010091626.18636.neil.whelchel@gmail.com>
<AANLkTimayTM__hHu9RoiLaNhzfpNY6Vo5y4OkbX_sV=o@mail.gmail.com>
<4CB34D69.6060108@emolecules.com>
<4CB4149D.8030803@gmail.com>
<4CB41902.1020503@postnewspapers.com.au>
<alpine.DEB.2.00.1010120118030.21889@asgard.lang.hm>
<4CB4542E.5010406@vmsinfo.com>
<23516.1286891790@sss.pgh.pa.us>
Tom Lane wrote:
> Mladen Gogala <mladen.gogala@vmsinfo.com> writes:
>
>> The number of rows is significantly smaller, but the table contains
>> rather significant "text" field which consumes quite a bit of TOAST
>> storage and the sizes are comparable. Postgres read through 27GB in 113
>> seconds, less than 2 minutes and oracle took 2 minutes 37 seconds to
>> read through 35GB. I stand corrected: there is nothing wrong with the
>> speed of the Postgres sequential scan.
>>
>
> Um ... the whole point of TOAST is that the data isn't in-line.
> So what Postgres was actually reading through was probably quite a
> lot less than 27Gb. It's probably hard to make a completely
> apples-to-apples comparison because the two databases are so different,
> but I don't think this one proves that PG is faster than Oracle.
>
> regards, tom lane
>
As is usually the case, you're right. I will try copying the table to
Postgres over the weekend, my management would not look kindly upon my
copying 35GB of the production data during the working hours, for the
scientific reasons. I have the storage and I can test, I will post the
result. I developed quite an efficient Perl script which does copying
without the intervening CSV file, so that the copy should not take more
than 2 hours. I will be able to impose a shared lock on the table over
the weekend, so that I don't blow away the UNDO segments.
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com
The Leader in Integrated Media Intelligence Solutions
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mladen.gogala@vmsinfo.com, tgl@sss.pgh.pa.us, david@lang.hm, craig@postnewspapers.com.au, tivv00@gmail.com
Subject: Re: Slow count(*) again...
In-Reply-To: <4CB46AE2.7030006@vmsinfo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox