Andres Freund <andres@anarazel.de> writes: > On 2015-07-06 11:49:54 -0400, Tom Lane wrote: >> Rather than reverting cab9a0656c36739f, which would re-introduce a >> different performance problem, perhaps we could have COPY create a new >> relfilenode when it does this. That should be safe if the table was >> previously empty.
> I'm not convinced that cab9a0656c36739f needs to survive in that > form. To me only allowing one COPY to benefit from the wal_level = > minimal optimization has a significantly higher cost than > cab9a0656c36739f.
What evidence have you got to base that value judgement on?
cab9a0656c36739f was based on an actual user complaint, so we have good evidence that there are people out there who care about the cost of truncating a table many times in one transaction. On the other hand, I know of no evidence that anyone's depending on multiple sequential COPYs, nor intermixed COPY and INSERT, to be fast. The original argument for having this COPY optimization at all was to make restoring pg_dump scripts in a single transaction fast; and that use-case doesn't care about anything but a single COPY into a virgin table.
We have to backpatch this fix, so it must be both simple and effective.
Heikki's suggestions may be best, maybe not, but they don't seem backpatchable.
Tom's suggestion looks good. So does Andres' suggestion. I have coded both.
And what reason is there to think that this would fix all the problems?
I don't think either suggested fix could be claimed to be a great solution, since there is little principle here, only heuristic. Heikki's solution would be the only safe way, but is not backpatchable.
Forcing SKIP_FSM to always extend has no negative side effects in other code paths, AFAICS.
Patches attached. Martijn, please verify.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services