... btw, in the penny wise and pound foolish department, I observe that smgrdounlink calls mdunlink separately for each possibly existing fork of a relation to be dropped. That means we are queuing a separate fsync queue entry for each fork, and could immediately save a factor of four in FORGET_RELATION_FSYNC traffic if we were to redefine those queue entries as applying to all forks. The only reason to have a per-fork variant, AFAICS, is for smgrdounlinkfork(), which is used nowhere and exists only because I was too chicken to remove the functionality outright in commit ece01aae479227d9836294b287d872c5a6146a11. But given that we know the fsync queue can be a bottleneck, my vote is to refactor mdunlink to apply to all forks and send only one message.
I am also wondering whether it's really necessary to send fsync request messages for backend-local relations. If rnode.backend says it's local, can't we skip sending the fsync request? All local relations are flush-on-crash anyway, no? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers