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 protosci
Robert Haas 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.
regards, tom l
On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas wrote:
> On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> The fact that the file was "modified" twice after being removed at rev
>>> 2.88 seems really wacko. Are you sure that's not contributing to what
>>> we're seeing her
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
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 s
2010/8/29 Tom Lane :
> Martijn van Oosterhout 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 sl
Martijn van Oosterhout 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 intermediate valu
On Sun, Aug 29, 2010 at 11:23:29AM -0400, Tom Lane wrote:
> Pavel Stehule 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 double evaluatio
2010/8/29 Tom Lane :
> Pavel Stehule writes:
>> 2010/8/29 Tom Lane :
>>> 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 bool
Pavel Stehule writes:
> 2010/8/29 Tom Lane :
>> 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 boolean
> operators in SQL functi
2010/8/29 Tom Lane :
> Pavel Stehule 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.
Pavel Stehule 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.
regards
On Thu, Aug 26, 2010 at 22:59, Cristian Bittel 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, just
> monitori
Hello
2010/8/29 Marko Tiikkaja :
> On 29 Aug 2010, at 13:20, Pavel Stehule 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 - planner see inside SQL function - so you don't
ne
On 29 Aug 2010, at 13:20, Pavel Stehule 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 (pgsql-hackers@postgresql.org)
To make changes to yo
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))
16 matches
Mail list logo
