On 2015-03-30 09:33:57 +0530, Amit Kapila wrote: > In the past, I have observed in one of the Write-oriented tests that > backend's have to flush the pages by themselves many a times, so > in above situation that can lead to more severe bottleneck.
Yes. > > I've prototyped solving this for heap relations moving the smgrnblocks() > > + smgrextend() calls to RelationGetBufferForTuple(). With some care > > (including a retry loop) it's possible to only do those two under the > > extension lock. That indeed fixes problems in some of my tests. > > > > So do this means that the problem is because of contention on extension > lock? Yes, at least commonly. Obviously the extension lock would be less of a problem if we were better at having clean victim buffer ready. > > I'm not sure whether the above is the best solution however. > > Another thing to note here is that during extension we are extending > just one block, won't it make sense to increment it by some bigger > number (we can even take input from user for the same where user > can specify how much to autoextend a relation when the relation doesn't > have any empty space). During mdextend(), we might increase just one > block, however we can register the request for background process to > increase the size similar to what is done for fsync. I think that's pretty much a separate patch. Made easier by moving things out of under the lock maybe. Other than that I'd prefer not to mix things. There's a whole bunch of unrelated complexity that I don't want to attach to the topic at the same time (autovacuum truncayting again and so on). Greetings, Andres Freund -- Andres Freund 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
