Обсуждение: partial index on system indexes?

It seems bootstrap parser(bootparse.y) does not accept partial index
definitions. Is there any reason for this?
--
Tatsuo Ishii

Tatsuo Ishii wrote:
> It seems bootstrap parser(bootparse.y) does not accept partial index
> definitions. Is there any reason for this?

Probably just because we never needed them.  We could add it, or just
create the index later in the initdb script.  That later seems easier.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Tatsuo Ishii wrote:
> It seems bootstrap parser(bootparse.y) does not accept partial index
> definitions. Is there any reason for this?

In private email with Tatsuo, I learned it is for the new loadable
encoding patch, and he wants to use the index from the syscache.  The
reason for the partial index is because the index itself would not be
unique, but a partial index would be unique.

Because the index is part of the syscache, we have to create it as part
of initdb bootstrap, rather than in the initdb script.

Tatsuo mentioned there is a boolean, and he only wants cases where the
boolean is true, and such values are unique.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> It seems bootstrap parser(bootparse.y) does not accept partial index
> definitions. Is there any reason for this?

Why should it?  The boot parser need handle only a minimal set of
operations.  Why is there any need to handle partial indexes there?
        regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> In private email with Tatsuo, I learned it is for the new loadable
> encoding patch, and he wants to use the index from the syscache.  The
> reason for the partial index is because the index itself would not be
> unique, but a partial index would be unique.
> Because the index is part of the syscache, we have to create it as part
> of initdb bootstrap, rather than in the initdb script.

This sounds like a really bad idea to me.  A syscache based on a partial
index is almost certainly not going to work.

Before we invest in a lot of effort making bootstrap, syscache, and who
knows what else support partial indexes, I want to see a very clear
explanation why we must do it.  Note I am looking for "*must* do it",
not "it makes this other part of the system a little simpler".
        regards, tom lane

> This sounds like a really bad idea to me.  A syscache based on a partial
> index is almost certainly not going to work.
> 
> Before we invest in a lot of effort making bootstrap, syscache, and who
> knows what else support partial indexes, I want to see a very clear
> explanation why we must do it.  Note I am looking for "*must* do it",
> not "it makes this other part of the system a little simpler".

Ok, I'm going to look into bootstrap and syscache etc. codes more to
study why "a syscache based on a partial index is almost certainly not
going to work" and how hard it would be to fix that when I have spare
time.

In the mean time I'm going to add an unique index to pg_conversion
(actually it is not so unique one. I will add the oid column to it so
that it seems "unique") and use SearchSysCacheList(). As far as I know
this is the only way to avoid heap scan every time an encoding
conversion is performed if partial index cannot be used. 

Once I thought of a conversion lookup cache, but it seems impossible
to implent it since the cache needs to be invalidated when the schema
search path is changed.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Once I thought of a conversion lookup cache, but it seems impossible
> to implent it since the cache needs to be invalidated when the schema
> search path is changed.

On the contrary, that seems very easy to do.  There is a hook to let you
get control whenever a syscache inval event is received.  Look at the
way that namespace.c arranges to invalidate its cache of the search
path OIDs whenever pg_namespace is modified.
        regards, tom lane