Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary - Mailing list pgsql-performance

From Tom Lane
Subject Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
Date
Msg-id 19691.1404534696@sss.pgh.pa.us
Whole thread Raw
In response to stored procedure suddenly runs slowly in HOT STANDBY but fast in primary  (piuschan <pchan@contigo.com>)
Responses Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
List pgsql-performance
piuschan <pchan@contigo.com> writes:
> PostgreSQL: 9.1.11

> Since July 1, one SP suddenly runs slowly in HOT STANDBY server. After
> investigation, I can narrow the problem to one particular query in SP.

>    SELECT MIN(locate_id) INTO v_min_locate_id
>    FROM   event_startstop
>    WHERE  beacon_id = p_beacon_id
>    AND    locate_id IS NOT NULL
>    AND    network_timestamp BETWEEN p_rpt_start_ts AND p_rpt_end_ts;

> (6) the event_startstop is a parent table with 406 children tables

TBH, the astonishing part of this report is not that it's slow, but
that it ever was not slow.  9.1 is not capable of avoiding scanning
the other 405 child tables when given a parameterized query such as
this one.  (You haven't said, but I suppose that the child tables
are partitioned on beacon_id and/or network_timestamp, so that knowledge
of the constants these columns are being compared to is essential for
doing constraint exclusion.)

You could work around that by inserting constants into the query with
EXECUTE, but a better answer would be to update to 9.2 or later.

            regards, tom lane


pgsql-performance by date:

Previous
From: piuschan
Date:
Subject: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
Next
From: Nicolas Paris
Date:
Subject: PGSQL 9.3 - billion rows