X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 849319FB383 for ; Wed, 2 Aug 2006 00:15:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 77628-09 for ; Wed, 2 Aug 2006 00:15:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id CF3009FB381 for ; Wed, 2 Aug 2006 00:15:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k723FBDO029158; Tue, 1 Aug 2006 23:15:11 -0400 (EDT) To: Eugeny N Dzhurinsky cc: pgsql-performance@postgresql.org Subject: Re: Query/database optimization In-reply-to: <20060801131837.GC4221@office.redwerk.com> References: <20060801131837.GC4221@office.redwerk.com> Comments: In-reply-to Eugeny N Dzhurinsky message dated "Tue, 01 Aug 2006 16:18:37 +0300" Date: Tue, 01 Aug 2006 23:15:11 -0400 Message-ID: <29157.1154488511@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.181 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/23 X-Sequence-Number: 20208 Eugeny N Dzhurinsky writes: > [slow query] The bulk of your time seems to be going into this indexscan: > -> Index Scan using task_scheduler_icustomer_id on task_scheduler ts (cost=2.03..11.51 rows=1 width=51) (actual time=2.785..2.785 rows=0 loops=4161) > Index Cond: ("outer".customer_id = ts.customer_id) > Filter: ((get_available_pages(task_id, customer_id) > 0) AND ((get_check_period(task_id, next_check) IS NULL) OR ((date_part('epoch'::text, get_check_period(task_id, next_check)) - date_part('epoch'::text, (timenow())::timestamp without time zone)) < 3600::double precision)) AND (status <> 1) AND ((((start_time)::time with time zone < ('now'::text)::time(6) with time zone) AND ((stop_time)::time with time zone > ('now'::text)::time(6) with time zone)) OR ((start_time IS NULL) AND (stop_time IS NULL))) AND (NOT (hashed subplan))) > SubPlan > -> Unique (cost=2.02..2.03 rows=1 width=4) (actual time=0.617..0.631 rows=3 loops=1) > ... I kinda doubt that the index search itself is that slow --- doubtless the problem comes from having to evaluate that filter condition on a lot of rows. How fast are those functions you're calling? regards, tom lane