Re: Query - CPU issue - Mailing list pgsql-general

From Kevin Grittner
Subject Re: Query - CPU issue
Date
Msg-id 1379563391.18504.YahooMailNeo@web162906.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: Query - CPU issue  (Jayadevan <maymala.jayadevan@gmail.com>)
Responses Re: Query - CPU issue  (Jayadevan <maymala.jayadevan@gmail.com>)
List pgsql-general
Jayadevan <maymala.jayadevan@gmail.com> wrote:
> Kevin Grittner-5 wrote
>> What is the longest you have let it run, in hours or minutes?
>
> I let it run for about 10 minutes and killed it.

Doing the arithmetic, that means if the estimated row counts from
the explain of the outer query are right, the function must average
at least 57 ms per call.

> Kevin Grittner-5 wrote
>> By the way, IMMUTABLE has to be wrong here, since the results
>> depend on the state of the database.  STABLE is likely the right
>> designation.
>
> The data will not change unless I do a reload of the data set
> manually. In that case, is IMMUTABLE wrong?

Yes.  I don't think that's any part of your current problem, but it
is kinda asking for trouble to get that wrong.  IMMUTABLE means
that regardless of how the data in the database changes, calling
the function with any given set of arguments will always return the
same results.  STABLE means that during the course of running a
single query the same arguments always yield the same results.

> Here is the EXPLAIN (no analyze)
> [ explain of outer query showing 10515 calls to a function ]

We already had this.  I was asking for you to get EXPLAIN ANALYZE
output for a run of the SELECT statement inside the geoip_city()
function.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-general by date:

Previous
From: Jayadevan
Date:
Subject: Re: Query - CPU issue
Next
From: David Johnston
Date:
Subject: Re: How to know if a query is semantically correct without execute it?