X-Original-To: pgsql-performance@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 34D7B475A8D for ; Wed, 9 Apr 2003 12:19:14 -0400 (EDT) Received: from davinci.ethosmedia.com (unknown [209.10.40.251]) by postgresql.org (Postfix) with ESMTP id 6C186475458 for ; Wed, 9 Apr 2003 12:19:13 -0400 (EDT) Received: from [63.195.55.98] (HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.0.2) with ESMTP id 2953011; Wed, 09 Apr 2003 09:19:13 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Organization: Aglio Database Solutions To: , Subject: Re: [SQL] Yet Another (Simple) Case of Index not used Date: Wed, 9 Apr 2003 09:18:45 -0700 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200304090918.45275.josh@agliodbs.com> Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-32.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/87 X-Sequence-Number: 1593 Denis, > Are you saying the 7.4 'group by' trick would be faster than the simple > select count(*)? That seems hard to believe, being that the request now h= as > to fetch / sort the data. I must be missing something. No, I'm saying that the 7.4 hash-aggregate is faster than the same query wa= s=20 under 7.2 or 7.3. Much faster. But it does little to speed up a raw=20 count(*). > The kind of requests that I am really interested in are: > select count(*) from table where table.column like 'pattern%' Hash-aggregates may, in fact, help with this. Care to try downloading the= =20 the source from CVS? > These seems to go much master on mysql (which I guess it not a MVCC > database? or wasn't the Innobase supposed to make it so?), They did incorporate a lot of MVCC logic into InnoDB tables, yes. Which me= ans=20 that if SELECT count(*) on an InnoDB table is just as fast as a MyISAM tabl= e,=20 then it is not accurate. This would be in keeping with MySQL's design=20 philosophy, which values performance and simplicity over accuracy and=20 precision -- the opposite of our philosophy. > So, in the meantime, I've decided to split up my data into two sets, > the static big tables which are handled by mysql, and the rest of it > handled by postgresql.... Hey, if it works for you, it's probably easier than dealing with the=20 PostgreSQL workarounds to this performance issue. I'll ask you to give=20 PostgreSQL a try for those tables again when 7.4 comes out. > ps: apologies for the cross-posting. De nada. The Performance list is the right place for this sort of questio= n=20 in the future. --=20 Josh Berkus Aglio Database Solutions San Francisco