Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 5750D6322EA for ; Wed, 14 Jul 2010 10:31:01 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 64934-07 for ; Wed, 14 Jul 2010 13:30:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.214.174]) by mail.postgresql.org (Postfix) with ESMTP id DD242632228 for ; Wed, 14 Jul 2010 10:30:47 -0300 (ADT) Received: by iwn7 with SMTP id 7so7021831iwn.19 for ; Wed, 14 Jul 2010 06:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=XJoOgIE+/U5qQuUY2h/ED+gEZ+8Jj4wTyudqKCW/I/4=; b=YciNTRKLGu5cfjLrHNdrDBMpqaQZnjIt6xPCSstQbWbVP/LTH5/mZN0xxCL0lu+apo RCqhz5q0qEkroK/WuIEpItdgsOPYrC+6yLhnzTz0XnChntmyh8haUuRPFL2ZG8sK+SJ9 XcXyRwWoxLJID/K++DmCTtTiny46FmsX9Qf6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fYlIbaZ1RGtdON7bOxJMN14UnLHA/5Z4kc/VjVEDg1Y3YUvkBGzppbDTcxYOf/mqTe coo5avuMUs8Xnfgf/X/IxOZd+LRFUo0MLONuBz19OwLotbCJiw5xnGJWqsBHRGj+JuzY ID3M30bwLGrsZ4A6np3rl/lLPN2xmU1NfVyJQ= Received: by 10.231.150.1 with SMTP id w1mr17988782ibv.7.1279114242184; Wed, 14 Jul 2010 06:30:42 -0700 (PDT) Received: from eddie (c-67-186-205-129.hsd1.ut.comcast.net [67.186.205.129]) by mx.google.com with ESMTPS id r3sm30374487ibk.1.2010.07.14.06.30.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Jul 2010 06:30:41 -0700 (PDT) Message-ID: <4c3dbc01.0350e70a.18fa.388a@mx.google.com> Date: Wed, 14 Jul 2010 07:30:39 -0600 From: Joshua Tolley To: pgsql-sql@postgresql.org Subject: Re: Question on COUNT performance References: <20100714123029.GH62243@spoetnik.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <20100714123029.GH62243@spoetnik.xs4all.nl> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.001 tagged_above=-5 required=5 tests=BAYES_40=-0.001 X-Spam-Level: X-Archive-Number: 201007/64 X-Sequence-Number: 34377 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 14, 2010 at 02:30:29PM +0200, Reinoud van Leeuwen wrote: > On Wed, Jul 14, 2010 at 09:58:10PM +1000, Anders ??stergaard Jensen wrote: > > SELECT count(*) AS count_all FROM "plan_events" WHERE (f_plan_event_acl= (17, > > plan_events.id)) > >=20 > > QUERY PLAN > >=20 > > -----------------------------------------------------------------------= ------------------------------------------------- > > Aggregate (cost=3D2859.77..2859.78 rows=3D1 width=3D0) (actual > > time=3D4641.720..4641.720 rows=3D1 loops=3D1) > > -> Seq Scan on plan_events (cost=3D0.00..2851.44 rows=3D3331 width= =3D0) > > (actual time=3D32.821..4640.116 rows=3D2669 loops=3D1) > > Filter: f_plan_event_acl(17, id) > > Total runtime: 4641.753 ms > > (4 rows) > >=20 > >=20 > >=20 > > What can I do to improve the performance?=20 >=20 > Have you tried 'select count (1)..."? If this helps at all, it's unlikely to help much. I remember having seen discussion somewhere that there's an optimization such that count(*) and count(1) do the same thing anyway, but I can't find it in the code immediately. In any case, if your WHERE clause frequently includes this function with 17 and id as arguments, and if f_plan_event_acl is immutable, you can create an index: CREATE INDEX foo_ix ON plan_events (f_plan_event_acl(17, id)); If PostgreSQL thinks that function will be true for a sufficiently small proportion of the rows in the table, it will use the index instead of a sequential scan, which might end up being faster. But the index won't help = you when you want to check values other than 17, e.g. SELECT count(*) FROM plan_events WHERE f_plan_event_acl(42, id) Another option might be to precalculate these data, if you have a relatively small set of values you pass to f_plan_event_acl(). A table somewhere could store the f_plan_events_acl() argument (17, as well as any other values you want to precalculate), and a count of plan_events rows where f_plan_events_acl() returns true with that argument. A set of triggers would ensure that whenever someone INSERTs, UPDATEs, or DELETEs a plan_events row, these counts are updated accordingly. Then you can refer to that table when you need a count. If values in other tables can change the results of f_plan_events_acl(), you'd need triggers there, too (and this method would probably start to become unworkably complicated). As an alternative to the precalculation option, you could also cache the results of this query somewhere, and presumably invalidate that cache using= a trigger on the plan_events table. Finally, you can try to improve performance of your function itself. If it's taking 4.6 sec. to read and process 2669 rows, either you're reading awfully slowly (VACUUM problems, perhaps?) or your f_plan_events_acl() function tak= es a long time to run. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkw9u/8ACgkQRiRfCGf1UMMyxQCfV6vzGtq3JGfgUMh0gIUANISZ G3UAn3afwbHoTBPu5J4wJ4unXRLPdKET =L3ZT -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig--