I'm looking at the combined patches 0003-0005, which are essentially all
about adding a function to obtain relation OID from (tablespace,
filenode). It takes care to look through the relation mapper, and uses
a new syscache underneath for performance.
One question about this patch, originally, was about the usage of
that relfilenode syscache. It is questionable because it would be the
only syscache to apply on top of a non-unique index. It is said that
this doesn't matter because the only non-unique values that can exist
would reference entries that have relfilenode = 0; and in turn this
doesn't matter because those values would be queried through the
relation mapper anyway, not from the syscache. (This is implemented in
the higher-level function.)
This means that there would be one syscache that is damn easy to misuse
.. and we've setup things so that syscaches are very easy to use in the
first place. From that perspective, this doesn't look good. However,
it's an easy mistake to notice and fix, so perhaps this is not a serious
problem. (I would much prefer for there to be a way to define partial
indexes in BKI.)
I'm not sure about the placing of the new SQL-callable function in
dbsize.c either. It is certainly not a function that has anything to do
with object sizes. The insides of it would belong more in lsyscache.c,
I think, except then that file does not otherwise concern itself with
the relation mapper so its scope would have to expand a bit. But this
is no place for the SQL-callable portion, so that would have to find a
different home as well.
The other option, of course, it to provide a separate caching layer for
these objects altogether, but given how concise this implementation is,
it doesn't sound too palatable.
Thoughts?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services