Skip site navigation (1) Skip section navigation (2)

Re: Making oidvector and int2vector variable-length

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Making oidvector and int2vector variable-length
Date: 2005-03-27 20:41:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Sun, Mar 27, 2005 at 12:44:41PM -0500, Tom Lane wrote:
>> I've been toying with the idea of converting the oidvector and
>> int2vector datatypes from fixed-width arrays to variable-length;
>> that is, stick a varlena length word on the front and store only
>> pronargs or indnatts entries instead of a fixed number.

> This mean that it would be possible to set FUNC_MAX_ARGS much higher
> without performance loss, right?  That alone sounds like a big win to
> me.

It wouldn't cost anything in terms of disk space.  I'm not sure about
performance implications --- there are a lot of MemSets floating around
that zero FUNC_MAX_ARGS worth of space, and I'm unsure if any of them
are in performance-critical paths.  Atsushi Ogawa got the most critical
ones recently, though.

Very likely we could kick it up to 100 or so without feeling any pain;
how high were you thinking?

(Since I wasn't thinking of making oidvector TOAST-capable, it wouldn't
be possible to set FUNC_MAX_ARGS higher than ~600 anyway without
exceeding the maximum index tuple size in pg_proc's index.)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-03-27 21:01:27
Subject: Re: _RollbackFunc : dead code?
Previous:From: Josh BerkusDate: 2005-03-27 19:43:53
Subject: Re: Bug 1500

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group