pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Eugeny N Dzhurinsky <bofh@redwerk.com>
To: pgsql-performance@postgresql.org
Subject: Re: Query/database optimization
Date: Wed, 2 Aug 2006 13:56:22 +0300
Message-ID: <20060802105622.GA2627@office.redwerk.com> (raw)
In-Reply-To: <29157.1154488511@sss.pgh.pa.us>
References: <20060801131837.GC4221@office.redwerk.com>
	<29157.1154488511@sss.pgh.pa.us>

On Tue, Aug 01, 2006 at 11:15:11PM -0400, Tom Lane wrote:
> Eugeny N Dzhurinsky <bofh@redwerk.com> 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?

Well, not really fast, especially get_available_pages

there is special table with history of changes, and there is a view for latest
changes per task, and this function selects all records from a view for given
ID, then calculates sum of pages of tasks and then calculates number of
available pages as number of allowed pages deduct number of processed pages.

probably there is bottleneck in this view selection?

-- 
Eugene N Dzhurinsky



view thread (3+ messages)

Message-ID: <20060802105622.GA2627@office.redwerk.com>
Permalink:  ../20060802105622.GA2627@office.redwerk.com/
Also on:    postgresql.org/message-id/20060802105622.GA2627@office.redwerk.com

 · 

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: bofh@redwerk.com
  Subject: Re: Query/database optimization
  In-Reply-To: <20060802105622.GA2627@office.redwerk.com>

* 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