Greg Stark <stark@mit.edu> writes:
> On Mon, Mar 25, 2013 at 9:53 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> That would make it harder to construct a degenerate case
> I don't think it's hard at all. It's the same as the case Simon wants
> to solve except that the cost is incurred in a different way. Imagine
> a system where there's a huge data load to a table which is then
> read-only for an OLTP system. Until vacuum comes along -- and it may
> never since the table never sees deletes or updates -- every
> transaction needs to do a clog lookup for every tuple it sees. That
> means a significant cpu slowdown for every row lookup forever more. To
> save a one-time i/o cost.
If I read Simon's original mail correctly, he was proposing that
individual SELECTs would update some hint bits but eventually "get
tired" and stop doing that. So repeated queries would eventually get
all the hint bits set in a scenario such as you describe. It's less
clear what would happen in a scenario where there's a steady flow of
new updates.
This is clearly worth thinking about and trying to find better solutions
for. I'm only against trying to solve it in the 9.3 timeframe. It will
take a lot longer than that to get something that works tolerably well.
regards, tom lane
