Hi,
On 2013-06-27 17:33:04 -0400, Alvaro Herrera wrote:
> 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.)
Well, you can even query the syscache without hurt for mapped relations,
you just won't get an answer. The only thing you may not do because it
would yield multiple results is to query the syscache with
(tablespace, InvalidOid/0). Which is still not nice although it doesn't
make much sense to query with InvalidOid.
> 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.
Not happy with that myself. I only placed the function there because
pg_relation_filenode() already was in it. Happy to change if somebody
has a good idea.
> (I would much prefer for there to be a way to define partial
> indexes in BKI.)
I don't think that's the hard part, it's that we don't use the full
machinery for updating indexes but rather the relatively simplistic
CatalogUpdateIndexes(). I am not sure we can guarantee that the required
infrastructure is available in all the cases to support doing generic
predicate evaluation.
Should bki really be the problem we probably could create the index
after bki based bootstrapping finished.
Thanks,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services