Change made.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > In fact, I now see that there was no such problem. I do wonder why the
> > 32 is there, though? Shouldn't it be 6 or something like that?
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In fact, I now see that there was no such problem. I do wonder why the
> 32 is there, though? Shouldn't it be 6 or something like that?
Whoever it was was too lazy to count accurately ;-)
I guess I'd vote for changing the code to be
sys = mal
In fact, I now see that there was no such problem. I do wonder why the
32 is there, though? Shouldn't it be 6 or something like that?
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have applied th
Good question. Looked like a possible buffer overrun to me. Of course,
I botched it up. I will fix it.
---
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have applied the attached patch which change
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have applied the attached patch which changes NAMEDATALEN to 64 and
> FUNC_MAX_ARGS/INDEX_MAX_KEYS to 32.
What is the reasoning behind the following change?
Index: src/bin/psql/command.c
===
I have applied the attached patch which changes NAMEDATALEN to 64 and
FUNC_MAX_ARGS/INDEX_MAX_KEYS to 32. Hopefully this will keep people
happy for a few more years.
initdb required.
---
Christopher Kings-Lynne wrote:
> >
I am working on a patch to increase these as agreed. I found this
interesting, from the 6.3 release notes:
Increase 16 char limit on system table/index names to 32 characters(Bruce)
The limited to be 16 chars until 6.3 in 1998-03-01.
> > NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
> > which one we prefer.
> >
> > The conservative approach would be to go for 64 and perhaps increase it
> > again in 7.4 after we get feedback and real-world usage. If we go to
> > 128, we will have trouble decreasing it
Bruce Momjian wrote:
> OK, seems we have not come to a decision yet on this.
>
> Do we have agreement to increate FUNC_MAX_ARGS to 32?
>
> NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
> which one we prefer.
>
> The conservative approach would be to go for 64 and perhap
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Do we have agreement to increate FUNC_MAX_ARGS to 32?
I believe so.
> NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
> which one we prefer.
> The conservative approach would be to go for 64 and perhaps increase it
> again in 7.4
OK, seems we have not come to a decision yet on this.
Do we have agreement to increate FUNC_MAX_ARGS to 32?
NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
which one we prefer.
The conservative approach would be to go for 64 and perhaps increase it
again in 7.4 after we
Bruce Momjian wrote:
> Tom Lane wrote:
>
>>Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>>OK, time to get moving folks. Looks like the increase in the function
>>>args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
>>
>>I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shou
Bruce Momjian wrote:
> Tom Lane wrote:
>>I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
>>too much. But have we done equivalent checks on NAMEDATALEN? In
>>particular, do we know what it does to the size of template1?
> No, I thought we saw the number, was 30%? No, we di
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, time to get moving folks. Looks like the increase in the function
> > args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
>
> I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
> too much. But
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, time to get moving folks. Looks like the increase in the function
> args to 32 and the NAMEDATALEN to 128 has been sufficiently tested.
I'm convinced by Joe's numbers that FUNC_MAX_ARGS = 32 shouldn't hurt
too much. But have we done equivalent che
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> 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 ?
Both.
> Also, (imho ;) btree index support should be done for all array types
> which have comparison ops for e
OK, time to get moving folks. Looks like the increase in the function
args to 32 and the NAMEDATALEN to 128 has been sufficiently tested. Tom
has some ideas on removing some memset() calls for function args to
speed things up, but we don't have to wait for that go get going. The
end of August
Hannu Krosing wrote:
> On Sat, 2002-08-03 at 23:20, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> 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 neede
On Sat, 2002-08-03 at 23:20, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> 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 u
Tom Lane wrote:
> Did you happen to make any notes about the disk space occupied by the
> database? One thing I was worried about was the bloat that'd occur
> in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from
> costing disk space, this would indirectly slow things down due to
Hannu Krosing <[EMAIL PROTECTED]> 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.
Even if we wanted to do that work, there'd be some serious breakage
of client queries because of the historical di
On Sat, 2002-08-03 at 18:41, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > I ran a crude test as follows (using a PHP script on the same machine.
> > Nothing else going on at the same time):
>
> > do 100 times
> >select 2+2+2+2+2+2+ ... iterated 9901 times
>
> > The results w
Tom Lane wrote:
> Did you happen to make any notes about the disk space occupied by the
> database? One thing I was worried about was the bloat that'd occur
> in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from
> costing disk space, this would indirectly slow things down due to
Joe Conway <[EMAIL PROTECTED]> writes:
> I ran a crude test as follows (using a PHP script on the same machine.
> Nothing else going on at the same time):
> do 100 times
>select 2+2+2+2+2+2+ ... iterated 9901 times
> The results were as follows:
> INDEX_MAX_KEYS1632 64 128
Tom Lane wrote:
> No, it was a 2% hit on rather slow functions with only one call made
> per query issued by the client. This is not much of a stress test.
>
> A more impressive comparison would be
>
> select 2+2+2+2+2+2+ ... (iterate 1 times or so)
>
> and see how much that slows down.
I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't terribly concerned because this wasn't a 2% on normal workload
> test, it was a 2% bang on function calls as fast as you can test.
No, it was a 2% hit on rather slow functions with only one call made
per query issued by the client. This is not
...
> I wasn't terribly concerned because this wasn't a 2% on normal workload
> test, it was a 2% bang on function calls as fast as you can test.
Yeah, good point. But if we can get it back somehow that would be even
better :)
- Thomas
---(end of broadc
Thomas Lockhart wrote:
> > > With FUNC_MAX_ARGS=16:
> > > (average = 28.6 seconds)
> > > With FUNC_MAX_ARGS=32:
> > > (average = 29.15 seconds)
>
> That is almost a 2 percent cost. Shall we challenge someone to get us
> back 2 percent from somewhere before the 7.3 release? Optimizing a hot
> spot
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
>> Actually, plpgsql is pretty expensive too. The thing to be benchmarking
>> is applications of plain old built-in-C functions and operators.
> I thought part of the justification for this wa
On Fri, Aug 02, 2002 at 12:35:10PM -0400, Daniel Wickstrom wrote:
>
> On the other hand, all of the web server stuff is implemented on Aolserver
> which uses Tcl as a scripting language.
I think this is why I was confused. Thanks, all.
A
--
Andrew Sullivan
> "Marc" == Marc G Fournier <[EMAIL PROTECTED]> writes:
Marc> On Fri, 2 Aug 2002, Andrew Sullivan wrote:
>> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote: > >
>> Actually, plpgsql is pretty expensive too. The thing to be
>> benchmarking > is applications of plain o
On Fri, 2002-08-02 at 09:28, Marc G. Fournier wrote:
> On Fri, 2 Aug 2002, Andrew Sullivan wrote:
>
> > On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
> > >
> > > Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> > > is applications of plain old built-in-C func
On Fri, 2 Aug 2002, Andrew Sullivan wrote:
> On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
> >
> > Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> > is applications of plain old built-in-C functions and operators.
>
> I thought part of the justification for
On Fri, Aug 02, 2002 at 10:39:47AM -0400, Tom Lane wrote:
>
> Actually, plpgsql is pretty expensive too. The thing to be benchmarking
> is applications of plain old built-in-C functions and operators.
I thought part of the justification for this was for the OpenACS
guys; don't they write everyt
Rod Taylor <[EMAIL PROTECTED]> writes:
> Perhaps I'm not remembering correctly, but don't SQL functions still
> have an abnormally high cost of execution compared to plpgsql?
> Want to try the same thing with a plpgsql function?
Actually, plpgsql is pretty expensive too. The thing to be benchm
Perhaps I'm not remembering correctly, but don't SQL functions still
have an abnormally high cost of execution compared to plpgsql?
Want to try the same thing with a plpgsql function?
On Thu, 2002-08-01 at 18:23, Neil Conway wrote:
> Ok, here are some crude benchmarks to attempt to measure th
On Thu, 1 Aug 2002, Thomas Lockhart wrote:
> > > With FUNC_MAX_ARGS=16:
> > > (average = 28.6 seconds)
> > > With FUNC_MAX_ARGS=32:
> > > (average = 29.15 seconds)
>
> That is almost a 2 percent cost. Shall we challenge someone to get us
> back 2 percent from somewhere before the 7.3 release? Opt
> > With FUNC_MAX_ARGS=16:
> > (average = 28.6 seconds)
> > With FUNC_MAX_ARGS=32:
> > (average = 29.15 seconds)
That is almost a 2 percent cost. Shall we challenge someone to get us
back 2 percent from somewhere before the 7.3 release? Optimizing a hot
spot might do it...
Thanks. That looks acceptable to me, and a good test.
---
Neil Conway wrote:
> Ok, here are some crude benchmarks to attempt to measure the effect of
> changing FUNC_MAX_ARGS. The benchmark script executed:
>
> CREATE FUN
Ok, here are some crude benchmarks to attempt to measure the effect of
changing FUNC_MAX_ARGS. The benchmark script executed:
CREATE FUNCTION test_func(int, int, int, int, int, int, int, int)
RETURNS INTEGER AS 'SELECT $1 + $2 + $3 + $4 + $5 + $6 + $7 + $8'
LANGUAGE 'sql' VOLATILE;
Followed by 3
40 matches
Mail list logo
