On 8 July 2011 10:44, Vincent de Phily
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
> 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 da
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 broadcast
>> 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=# EXPLAI
RM] Slow set-returning 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 see
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 h
> 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, bt
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:
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 NUL
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
10 matches
Mail list logo
