On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
Hi,
I have a delete query taking 7.2G of ram (and counting) but I do not
understant why so much memory is necessary. The server has 12G, and
I'm afraid it'll go into swap. Using postgres 8.3.14.
I'm purging some old data from table
On 8 July 2011 10:44, Vincent de Phily
vincent.deph...@mobile-devices.fr wrote:
On Friday 08 July 2011 10:05:47 Dean Rasheed wrote:
On Thu, 2011-07-07 at 15:34 +0200, vincent dephily wrote:
Hi,
I have a delete query taking 7.2G of ram (and counting) but I do not
understant why so much
I've posted the patch here:
http://archives.postgresql.org/pgsql-patches/2008-01/msg00123.php
Dean.
_
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx
---(end of
Is there any way that I can see what execution plan is being used
internally by the functions?
Not directly, but you can do this:
postgres=# PREPARE p (int4) AS SELECT id FROM foo WHERE lower(name) LIKE
'foo' ORDER BY id OFFSET 0 LIMIT $1;
PREPARE
postgres=# EXPLAIN EXECUTE
Hi,
I have been having difficulty with some functions which return sets of
rows. The functions seem to run very slowly, even though the queries
they run execute very quicky if I run them directly from psgl.
Typically these queries are only returning a few hundred rows with my
real data.
I have
functions
CC: [EMAIL PROTECTED]; pgsql-performance@postgresql.org
On Jan 20, 2008 9:34 AM, Heikki Linnakangas wrote:
Dean Rasheed wrote:
I have been having difficulty with some functions which return sets of
rows. The functions seem to run very slowly, even though the queries
they run
It looks like the problem is that the UNION is taken as producing plain
text output, as you can see with \d:
regression=# \d foo
Table public.foo
Column | Type | Modifiers
+--+---
a | foo_text | not null
b | text |
Indexes:
foo_pkey PRIMARY KEY, btree (a)
Hi,
I am having a performance problem trying to query a view which is a
UNION ALL of 2 tables. I have narrowed the problem down to my use of
DOMAINS in the underlying table. So in the test-case below, when the
column a is of domain type foo_text, the query runs slowly using
the following plan:
Hi,
I am having performance problems running a number of queries
involving views based on non-strict functions. I have reproduced the
problem with the simple test-case below which shows how the query plan
is different depending on whether the view uses strict or non-strict
functions (even though
Ah yes, I see the problem. I see that it is also going to be a problem where I
have used CASE..WHEN in the select list of views :-(
Naively, couldn't the subquery be pulled up if any non-nullable columns from
the right table t2 were automatically wrapped in a simple function which
returned
10 matches
Mail list logo
