Hello
I testing a simple use case and I was surprised with very slow
execution of SQL functions
create or replace function empty_string1(text)
returns bool as $$
select $1 is NULL or $1 = ''
$$ language sql;
postgres=# select count(empty_string1(CASE WHEN random() 0.5 THEN
NULL ELSE 'x' END))
On 29 Aug 2010, at 13:20, Pavel Stehule pavel.steh...@gmail.com wrote:
Is strange - so slow function can be replaced by plpgsql function and
it's faster
All your SQL language functions were VOLATILE.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list
Hello
2010/8/29 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 29 Aug 2010, at 13:20, Pavel Stehule pavel.steh...@gmail.com wrote:
Is strange - so slow function can be replaced by plpgsql function and
it's faster
All your SQL language functions were VOLATILE.
It's not a problem -
On Thu, Aug 26, 2010 at 22:59, Cristian Bittel cbit...@gmail.com wrote:
I still believe this exit code 128 is related to pgAdmin opened during the
clossing session on Remote Desktop. I have a Windows user login wich is not
administrator just no privileged user, it cannot start/stop services,
Pavel Stehule pavel.steh...@gmail.com writes:
I testing a simple use case and I was surprised with very slow
execution of SQL functions
The one case is inline-able and the other not (because it would result
in double evaluation of the volatile function random()).
See EXPLAIN VERBOSE.
2010/8/29 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I testing a simple use case and I was surprised with very slow
execution of SQL functions
The one case is inline-able and the other not (because it would result
in double evaluation of the volatile function
Pavel Stehule pavel.steh...@gmail.com writes:
2010/8/29 Tom Lane t...@sss.pgh.pa.us:
The one case is inline-able and the other not (because it would result
in double evaluation of the volatile function random()).
See EXPLAIN VERBOSE.
I understand now. So it means general advice - don't use a
2010/8/29 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2010/8/29 Tom Lane t...@sss.pgh.pa.us:
The one case is inline-able and the other not (because it would result
in double evaluation of the volatile function random()).
See EXPLAIN VERBOSE.
I understand now.
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
I understand now. So it means general advice - don't use a boolean
operators in SQL function? This issue should be documented somewhere?
It has nothing to do with boolean operators, just
Martijn van Oosterhout klep...@svana.org writes:
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
It has nothing to do with boolean operators, just double evaluation.
I was wondering, wouldn't it be possible to avoid the double evaluation
by simply creating an extra slot for the
2010/8/29 Tom Lane t...@sss.pgh.pa.us:
Martijn van Oosterhout klep...@svana.org writes:
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
It has nothing to do with boolean operators, just double evaluation.
I was wondering, wouldn't it be possible to avoid the double evaluation
by
The new buildfarm machines huia and moa aren't doing terribly well
with the older PG branches. This isn't really those machines' fault;
what I find after a bit of digging is that we just didn't have good
support for 64-bit Solaris until relatively recently. In particular:
* There was no 64-bit
Apologies if this has already been covered, but do we have dates yet
for the next (and in the case of 7.4 and 8.0, final) set of point
releases? And what about 9.1alpha1?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing
On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The fact that the file was modified twice after being removed at rev
2.88 seems really wacko. Are you sure
Robert Haas robertmh...@gmail.com writes:
Apologies if this has already been covered, but do we have dates yet
for the next (and in the case of 7.4 and 8.0, final) set of point
releases?
No.
And what about 9.1alpha1?
Peter muttered something about doing that this week.
I wrote:
what I find after a bit of digging is that we just didn't have good
support for 64-bit Solaris until relatively recently. In particular:
BTW, just for the record: it's Solaris on 64-bit Intel that's at
issue. 64-bit Sparc support goes way back, as evidenced by the fact
that
16 matches
Mail list logo
