Hi List,
With automated queries where I have COLUMN IN (), I get a different plan
from COLUMN = (). That would make sense if there are several arguments,
but in the case with just one argument the penalty can be seveare. One
query went from 5s execution time to a few houndreds of mS when I
ch
Loan we offer all kind of loans.Register with us
On 11 Jul 2010, at 11:38, Marcus Engene wrote:
> Hi List,
>
> With automated queries where I have COLUMN IN (), I get a different plan from
> COLUMN = (). That would make sense if there are several arguments, but in the
> case with just one argument the penalty can be seveare. One query went fr
On 7/11/10 12:42 , Alban Hertroys wrote:
On 11 Jul 2010, at 11:38, Marcus Engene wrote:
Hi List,
With automated queries where I have COLUMN IN (), I get a different plan from
COLUMN = (). That would make sense if there are several arguments, but in the
case with just one argument the pen
Thank you both for the helpful explanations.
On Sat, Jul 10, 2010 at 11:48:29AM -0400, Tom Lane wrote:
> Oh, and one more thing: there is no "function cache".
Reading
http://www.postgresql.org/docs/8.3/static/plpgsql-implementation.html
section 38.10.2. "Plan Caching" had put that idea in my hea
On 11/07/2010 5:46 AM, Pavel Stehule wrote:
any using a non simple expression is very slow - so there can be some
a warning when people use it. Sometimes people don't know (me too),
when use expensive expression
for example
rowvar := (10,20)
it isn't simple - I am not sure, if it is true stil
On Fri, Jul 9, 2010 at 6:47 PM, Jayadevan M
wrote:
> So recovery happened to a point after I dropped the first table and before
> I dropped
> the second table. Why ?
Because you didn't disable recovery_target_inclusive, I guess.
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html#
