Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary
От | Tom Lane |
---|---|
Тема | Re: stored procedure suddenly runs slowly in HOT STANDBY but fast in primary |
Дата | |
Msg-id | 19691.1404534696@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | stored procedure suddenly runs slowly in HOT STANDBY but fast in primary (piuschan <pchan@contigo.com>) |
Ответы |
Re: stored procedure suddenly runs slowly in HOT STANDBY but fast
in primary
|
Список | 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 по дате отправления: