On Fri, 2007-11-16 at 11:06 -0500, Jonah H. Harris wrote:
> On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > I don't know about that. There are times when it is the right plan:
>
> Agreed. IMHO, there's nothing wrong with nested-loop join as long as
> it's being used proper
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
hubert depesz lubaczewski wrote:
On Fri, Nov 16, 2007 at 10:40:43AM +0100, Gábor Farkas wrote:
we are moving one database from postgresql-7.4 to postgresql-8.2.4.
any particular reason why not 8.2.5?
the distribution i use only has 8.2.4 currently.
gabor
---(end of
[EMAIL PROTECTED]
> The table was quite huge (say 20k of products along with detailed
> descriptions etc.) and was completely updated and about 12x each day, i.e.
> it qrew to about 12x the original size (and 11/12 of the rows were dead).
> This caused a serious slowdown of the application each day
Dean Rasheed <[EMAIL PROTECTED]> writes:
> 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 s
On Nov 18, 2007 8:29 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-11-09 at 13:12 -0600, Scott Marlowe wrote:
>
> > Note that my best time was at around 16 Meg work_mem. This data set
> > is MUCH bigger than 16 Meg, it's around 300-400 Meg. But work_mem
> > optimized out at 16 Meg. B
On Fri, 2007-11-09 at 13:12 -0600, Scott Marlowe wrote:
> Note that my best time was at around 16 Meg work_mem. This data set
> is MUCH bigger than 16 Meg, it's around 300-400 Meg. But work_mem
> optimized out at 16 Meg. Btw, I tried it going as high as 768 Meg,
> and it was still slower than 1
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
