Re: FUNC_MAX_ARGS benchmarks

On Sat, 2002-08-03 at 23:20, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > How hard would it be to change pg_proc.proargtypes from oidvector to _oid
>
> Lack of btree index support for _oid would be the first hurdle.

Is that index really needed, or is it there just to enforce uniqueness ?

Would the lookup not be in some internal cache most of the time ?

Also, (imho ;) btree index support should be done for all array types
which have comparison ops for elements at once (with semantics similar
to string) not one by one for individual types. It should be in some
ways quite similar to multi-key indexes, so perhaps some code could be
borrowed from there.

Otoh, It should be a SMOP to write support for b-tree indexes just for
_oid :-p , most likely one could re-use code from oidvector ;)

> Even if we wanted to do that work, there'd be some serious breakage
> of client queries because of the historical differences in output format
> and subscripting. (oidvector indexes from 0, _oid from 1. Which is
> pretty bogus, but if the regression tests are anything to judge by there
> are probably a lot of queries out there that know this.)

I would guess that oidvector is sufficiently obscure type and that
nobody actually uses oidvector for user tables.

It is also only used in two tables and one index in system tables:

hannu=# select relname,relkind from pg_class where oid in (
hannu-# select attrelid from pg_attribute where atttypid=30);
relname | relkind
---------------------------------+---------
pg_index | r
pg_proc_proname_narg_type_index | i
pg_proc | r
(3 rows)

> > This could also get the requested 2% speedup,
>
> I'm not convinced that _oid would be faster.

Neither am I, but it _may_ be that having generally shorter oid arrays
wins us enough ;)

> All in all, it doesn't seem worth the trouble compared to just kicking
> FUNC_MAX_ARGS up a notch. At least not right now. I think we've
> created quite enough system-catalog changes for one release cycle ;-)

But going to _oid will free us from arbitrary limits on argument count.
Or at least from small arbitrary limits, as there will probably still be
the at-least-three-btree-keys-must-fit-in-page limit (makes > 2600
args/function) and maybe some other internal limits as well.

------------------
Hannu