Re: [PERFORM] DELETE vs TRUNCATE explanation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PERFORM] DELETE vs TRUNCATE explanation
Date
Msg-id 24158.1342391832@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PERFORM] DELETE vs TRUNCATE explanation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
... 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: CompactCheckpointerRequestQueue versus pad bytes
Next
From: Tom Lane
Date:
Subject: Closing out the June commitfest