Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id AAD099FA385 for ; Mon, 8 Jan 2007 01:52:14 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 67787-05 for ; Mon, 8 Jan 2007 01:52:09 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from smtp114.sbc.mail.re2.yahoo.com (smtp114.sbc.mail.re2.yahoo.com [68.142.229.91]) by postgresql.org (Postfix) with SMTP id DE2DF9FA48D for ; Mon, 8 Jan 2007 01:52:08 -0400 (AST) Received: (qmail 67482 invoked from network); 8 Jan 2007 05:52:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-YMail-OSG:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:In-Reply-To:Importance; b=kUC9lNJFRsHdtDlg2wGX3vd2kQOSsc22V/+OCAL/3XsC+/xHxLm0PJ8jORe88eAN9WWMuJccTXZIlNQeo/gfbAeI2IUoWFM/q2/WrjUqHJ3hC2Ty2QhUGMtHPXKC7+xKz3QGsMFvUpfPc8sQKf7b5ikUXDSfrmo5wZbyGyEUe44= ; Received: from unknown (HELO dualcore) (adam.r@sbcglobal.net@75.2.73.81 with login) by smtp114.sbc.mail.re2.yahoo.com with SMTP; 8 Jan 2007 05:52:04 -0000 X-YMail-OSG: Ev2OVewVM1m0FOaOWaZisy.W5rxkPa6u45EwuDOkP_nJtqi8MAkH8GlS93Hz85iJiLu3fVJk6KomsnehcZINztAC2znXHsrMrx1SS8rv43.EqrUIlUTL00gbCobV7EvmfgqLQlBhicMYYc5.iVy14KW5lY5PrS7dusCxGEPBril8sn2hBRHyAUTCZmDV From: "Adam Rich" To: "'Joshua D. Drake'" , "'Tom Lane'" Cc: "'Craig A. James'" , "'PostgreSQL Performance'" Subject: Re: High update activity, PostgreSQL vs BigDBMS Date: Sun, 7 Jan 2007 23:53:05 -0600 Message-ID: <023701c732e9$449fa370$6400a8c0@dualcore> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 In-Reply-To: <1168225799.724.0.camel@localhost.localdomain> Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/95 X-Sequence-Number: 22696 Here's another, more drastic example... Here the order by / limit version runs in less than 1/7000 the time of the MAX() version. select max(item_id) from events e, receipts r, receipt_items ri where e.event_id=r.event_id and r.receipt_id=ri.receipt_id Aggregate (cost=10850.84..10850.85 rows=1 width=4) (actual time=816.382..816.383 rows=1 loops=1) -> Hash Join (cost=2072.12..10503.30 rows=139019 width=4) (actual time=155.177..675.870 rows=147383 loops=1) Hash Cond: (ri.receipt_id = r.receipt_id) -> Seq Scan on receipt_items ri (cost=0.00..4097.56 rows=168196 width=8) (actual time=0.009..176.894 rows=168196 loops=1) -> Hash (cost=2010.69..2010.69 rows=24571 width=4) (actual time=155.146..155.146 rows=24571 loops=1) -> Hash Join (cost=506.84..2010.69 rows=24571 width=4) (actual time=34.803..126.452 rows=24571 loops=1) Hash Cond: (r.event_id = e.event_id) -> Seq Scan on receipts r (cost=0.00..663.58 rows=29728 width=8) (actual time=0.006..30.870 rows=29728 loops=1) -> Hash (cost=469.73..469.73 rows=14843 width=4) (actual time=34.780..34.780 rows=14843 loops=1) -> Seq Scan on events e (cost=0.00..469.73 rows=14843 width=4) (actual time=0.007..17.603 rows=14843 loops=1) Total runtime: 816.645 ms select item_id from events e, receipts r, receipt_items ri where e.event_id=r.event_id and r.receipt_id=ri.receipt_id order by item_id desc limit 1 Limit (cost=0.00..0.16 rows=1 width=4) (actual time=0.047..0.048 rows=1 loops=1) -> Nested Loop (cost=0.00..22131.43 rows=139019 width=4) (actual time=0.044..0.044 rows=1 loops=1) -> Nested Loop (cost=0.00..12987.42 rows=168196 width=8) (actual time=0.032..0.032 rows=1 loops=1) -> Index Scan Backward using receipt_items_pkey on receipt_items ri (cost=0.00..6885.50 rows=168196 width=8) (actual time=0.016..0.016 rows=1 loops=1) -> Index Scan using receipts_pkey on receipts r (cost=0.00..0.02 rows=1 width=8) (actual time=0.010..0.010 rows=1 loops=1) Index Cond: (r.receipt_id = ri.receipt_id) -> Index Scan using events_pkey on events e (cost=0.00..0.04 rows=1 width=4) (actual time=0.009..0.009 rows=1 loops=1) Index Cond: (e.event_id = r.event_id) Total runtime: 0.112 ms -----Original Message----- From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Joshua D. Drake Sent: Sunday, January 07, 2007 9:10 PM To: Adam Rich Cc: 'Craig A. James'; 'Guy Rouillier'; 'PostgreSQL Performance' Subject: Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS On Sun, 2007-01-07 at 20:26 -0600, Adam Rich wrote: > I'm using 8.2 and using order by & limit is still faster than MAX() > even though MAX() now seems to rewrite to an almost identical plan > internally. Gonna need you to back that up :) Can we get an explain analyze? > Count(*) still seems to use a full table scan rather than an index scan. > There is a TODO out there to help this. Don't know if it will get done. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org