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#
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
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 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
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
Loan we offer all kind of loans.Register with us
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
