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: | 18578.1111956068@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-27 21:01:27 | Re: _RollbackFunc : dead code? |
Previous Message | Josh Berkus | 2005-03-27 19:43:53 | Re: Bug 1500 |