pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Mark Kirkwood <markir@paradise.net.nz>
To: Craig James <craig_james@emolecules.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: count * performance issue
Date: Sat, 08 Mar 2008 12:51:19 +1300
Message-ID: <47D1D4F7.9040502@paradise.net.nz> (raw)
In-Reply-To: <47D0AFC1.5070305@emolecules.com>
References: <f966c2ee0803052142l6a105678jfe2da92a0d9371@mail.gmail.com>
	<f966c2ee0803052143k4570d771o6c300647d3b987d@mail.gmail.com>
	<20080306060829.GA21084@a-kretschmer.de>
	<bf54be870803052215y5bb56235k5ea05ada1d701022@mail.gmail.com>
	<47CF8EA6.8070503@mark.mielke.cc>
	<20080306063643.GB21084@a-kretschmer.de>
	<f966c2ee0803052243w723e2866gbfc37128620d1c6d@mail.gmail.com>
	<B94D3180-BB72-43EB-BA1E-90CF53705386@fastcrypt.com>
	<f966c2ee0803060358k14dd7374h8ef3f4ca0818b04@mail.gmail.com>
	<3E9C3A51-C28E-4B75-9739-E344DAC72880@fastcrypt.com>
	<f966c2ee0803060443j3d9c1b66x5f59e00d084e841c@mail.gmail.com>
	<Pine.GSO.4.64.0803060813570.11897@westnet.com>
	<47D00DB2.7040007@emolecules.com>
	<18451.1204824562@sss.pgh.pa.us>
	<47D0AFC1.5070305@emolecules.com>

Craig James wrote:
> Tom Lane wrote:
>> Craig James <craig_james@emolecules.com> writes:
>>> Count() on Oracle and MySQL is almost instantaneous, even for very 
>>> large tables. So why can't Postgres do what they do?
>>
>> AFAIK the above claim is false for Oracle.  They have the same
>> transactional issues we do.
>
> My experience doesn't match this claim.  When I ported my application 
> from Oracle to Postgres, this was the single biggest performance 
> problem.  count() in Oracle was always very fast.  We're not talking 
> about a 20% or 50% difference, we're talking about a small fraction of 
> a second (Oracle) versus a minute (Postgres) -- something like two or 
> three orders of magnitude.
>

To convince yourself do this in Oracle:

EXPLAIN PLAN FOR SELECT count(*) FROM table_without_any_indexes

and you will see a full table scan. If you add (suitable) indexes you'll 
see something like an index full fast scan.


In fact you can make count(*) *very* slow indeed in Oracle, by having an 
older session try to count a table that a newer session is modifying and 
committing to. The older session's data for the count is reconstructed 
from the rollback segments - which is very expensive.

regards

Mark





view thread (62+ messages)  latest in thread

Message-ID: <47D1D4F7.9040502@paradise.net.nz>
Permalink:  ../47D1D4F7.9040502@paradise.net.nz/
Also on:    postgresql.org/message-id/47D1D4F7.9040502@paradise.net.nz

 · 

reply
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: markir@paradise.net.nz, craig_james@emolecules.com, tgl@sss.pgh.pa.us
  Subject: Re: count * performance issue
  In-Reply-To: <47D1D4F7.9040502@paradise.net.nz>

* 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