On Mon, Apr 16, 2012 at 3:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> Can we have a "soft" hot standby conflict that doesn't kill the query, >> but disables index-only-scans? > > Well, there wouldn't be any way for the planner to know whether an > index-only scan would be safe or not. I think this would have to look > like a run-time fallback. Could it be structured as "return that the > page's all-visible bit is not set, instead of failing?" Or am I > confused about where the conflict is coming from?
The starting point is that HS now offers 4 different mechanisms for avoiding conflicts, probably the best of which is hot standby feedback. So we only need to improve things if those techniques don't work for people. So initially, my attitude is lets throw a conflict and wait for feedback during beta. If we do need to do something, then introduce concept of a visibility conflict. On replay: If feedback not set, set LSN of visibility conflict on PROCs that conflict, if not already set. On query: If feedback not set, check conflict LSN against page, if page is later, check visibility. In terms of optimisation, I wouldn't expect to have to adjust costs at all. The difference would only show for long running queries and typically they don't touch too much new data as a fraction of total. The cost model for index only is pretty crude anyhow. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
