On Fri, Jan 23, 2009 at 11:25 AM, Howard Cole wrote:
> Francisco Figueiredo Jr. wrote:
>>
>> About the memory issue of Npgsql, did you try to use a prepared
>> statement for this? We have some performance improvements when
>> handling bytea values but only when the NpgsqlCommand.Prepare() method
>
On Fri, Jan 23, 2009 at 06:32:17PM +0300, Igor Katson wrote:
> Sam, I'm not sure if this is correct to do that, as you I don't want to
> remember what will happen, if you use NULL = NULL or upper(NULL) etc.:
>
> WHERE
>COALESCE(city_id = i_city_id, TRUE) AND
>COALESCE(edu_id = i_edu_id,
Clemens Schwaighofer wrote:
> On 01/22/2009 07:11 PM, Richard Huxton wrote:
>> Clemens Schwaighofer wrote:
>>> Hi,
>>>
>>> I just literally trashed my test server with one delete statement
>>> because the psql used up all its memory and started to swap like crazy.
>>>
>>> my delete looked like this
As I cannot do usual joins while using plproxy, there is a need to
perform a following set of operations:
get some (3 in fact) result columns from one function, then provide one
of this columns to another function as an array, and join the result of
the first function with the result of the se
Michael Glaesemann wrote:
On Jan 23, 2009, at 10:11 , Igor Katson wrote:
That one is awesome, thanks, I completely forgot about CASE
statement. The search func now looks as follows, and works perfectly:
CREATE OR REPLACE FUNCTION isocial_user_func.search_users
(i_city_id int, i_edu_id int, i
On Jan 23, 2009, at 10:11 , Igor Katson wrote:
That one is awesome, thanks, I completely forgot about CASE
statement. The search func now looks as follows, and works perfectly:
CREATE OR REPLACE FUNCTION isocial_user_func.search_users
(i_city_id int, i_edu_id int, i_firstname text, i_lastnam
Sam Mason wrote:
On Fri, Jan 23, 2009 at 02:16:34PM +0300, Igor Katson wrote:
a) If the input argument is NULL, then the corresponding select
statement will change from
column = arg
to
column IS NULL
I think you want to use the IS [NOT] DISTINCT FROM operator. It
works like the = an
On Fri, Jan 23, 2009 at 12:08:02PM +, Howard Cole wrote:
> Is there some nice SQL I can use to convert a BYTEA field into large
> objects?
You may be able to do something like:
SELECT oid, lowrite(lo_open(oid, 131072), (SELECT byteafield FROM tbl WHERE x)
FROM lo_create(NULL) o(oid);
Yo
On Fri, Jan 23, 2009 at 02:16:34PM +0300, Igor Katson wrote:
> a) If the input argument is NULL, then the corresponding select
> statement will change from
>
> column = arg
> to
> column IS NULL
I think you want to use the IS [NOT] DISTINCT FROM operator. It
works like the = and <> operators. i
Francisco Figueiredo Jr. wrote:
About the memory issue of Npgsql, did you try to use a prepared
statement for this? We have some performance improvements when
handling bytea values but only when the NpgsqlCommand.Prepare() method
is called.
I hope it helps.
Hi Francisco,
Yes it did help. T
2009/1/23, Igor Katson :
> I have a row search function, smth like
>
> CREATE OR REPLACE FUNCTION user_func.search_users
> (i_city_id int, i_edu_id int, i_first_name text, i_last_name text,
> limit_ int, offset_ int) RETURNS SETOF user.user AS $$
> . SELECT * FROM user WHERE
> city_id = i
On Fri, Jan 23, 2009 at 10:08 AM, Howard Cole wrote:
> Hi All,
>
Hi, Howard!
> Is there some nice SQL I can use to convert a BYTEA field into large
> objects?
>
> I am having some memory problems handling bytea parameters in Npgsql -
> getting out of memory errors. From reading various posts on
Raymond O'Donnell wrote:
On 23/01/2009 11:16, Igor Katson wrote:
How do I write a function without complex logic, which will do:
a) If the input argument is NULL, then the corresponding select
statement will change from
column = arg
to
column IS NULL
You could build your statement dy
Hi All,
Is there some nice SQL I can use to convert a BYTEA field into large
objects?
I am having some memory problems handling bytea parameters in Npgsql -
getting out of memory errors. From reading various posts on this I see
that bytea's can consume much more memory than the size of the o
On 23/01/2009 11:16, Igor Katson wrote:
> How do I write a function without complex logic, which will do:
> a) If the input argument is NULL, then the corresponding select
> statement will change from
>
> column = arg
> to
> column IS NULL
You could build your statement dynamically as a string,
I have a row search function, smth like
CREATE OR REPLACE FUNCTION user_func.search_users
(i_city_id int, i_edu_id int, i_first_name text, i_last_name text,
limit_ int, offset_ int) RETURNS SETOF user.user AS $$
. SELECT * FROM user WHERE
city_id = i_city_id
...
$$ language plpgsql;
How
But if I have my work mem small, shouldn't it then just end with "out
of memory" and not use up all the memory ...
On Fri, Jan 23, 2009 at 18:48, Grzegorz Jaśkiewicz wrote:
> try raising work_mem before the delete; on single connection :
>
> set work_mem=512000; DELETE FROM ..;
>
--
[ Cle
try raising work_mem before the delete; on single connection :
set work_mem=512000; DELETE FROM ..;
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
18 matches
Mail list logo
