On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Right. The major use I was hoping for from HS was exactly to be able to run
> long-running queries. In once case I am thinking of we have moved the
> business intelligence uses off the OLTP server onto a londiste replica, and
> I was really wanting to move that to a Hot Standby server.
I think Simon's focus on the High Availability use case has obscured
the fact that there are two entirely complementary (and conflicting)
use cases here. If your primary reason for implementing Hot Standby is
to be able to run long-running batch queries then will probably want
to set a very high max_standby_delay or even disable it entirely. If
you set max_standby_delay to 0 then the recovery will wait
indefinitely for your batch queries to finish. You would probably need
to schedule quiet periods in order to ensure that the recovery can
catch up periodically. If you also need high availability you would
need your HA replicas to run with a low max_standby_delay setting as
well.
This doesn't mean that the index btree split problem isn't a problem
though. It's just trading one problem for another. Instead of having
all your queries summarily killed regularly you would find recovery
pausing extremely frequently for a very long time, rather than just
when vacuum runs and for a limited time.
I missed the original discussion of this problem, do you happen to
remember the subject or url for the details?
--
greg
