Re: changeset generation v5-01 - Patches & git tree

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: changeset generation v5-01 - Patches & git tree
Дата
Msg-id 20130627221645.GP3757@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: changeset generation v5-01 - Patches & git tree  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund wrote:

> 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.

Yeah, I agree that it doesn't make sense to query for that.  The problem
is that something could reasonably be developed that uses the syscache
directly without checking whether the relfilenode is 0.

> > (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.

You're right, CatalogIndexInsert() doesn't allow for predicates, so
fixing BKI would not help.

I still wonder about having a separate cache.  Right now pg_class has
two indexes; adding this new one would mean a rather large decrease in
insert performance (50% more indexes to update than previously), which
is not good considering that it's inserted into for each and every temp
table creation -- that would become slower.  This would be a net loss
for every user, even those that don't want logical replication.  On the
other hand, table creation also has to add tuples to pg_attribute,
pg_depend, pg_shdepend and maybe other catalogs, so perhaps the
difference is negligible.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: updated emacs configuration
Следующее
От: Tom Lane
Дата:
Сообщение: Re: changeset generation v5-01 - Patches & git tree