We intsall postgresql 9.3.0 server from FreeBSD ports
http://svnweb.freebsd.org/ports/head/databases/postgresql93-server/ the
administrator says that he already contains this patch.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Performance-problem-in-PLPgSQL-tp576
> "dlight" == dlight writes:
dlight> So if I run function 1 with varible inside the query in
dlight> one session it's replan each time.
dlight> But if whant to teling postgres do not doing this, what shoud
dlight> i do?
dlight> We have more than 1 runs in one session with vari
Hello
can you try this patch (commit)
https://github.com/postgres/postgres/commit/a5f11e24a4d1afb213c780812a3df14c04d7f845#diff-fc73a24ee7d0692c2a0c639870223d70?
Regards
Pavel
2013/9/18 dlight
> So if I run function 1 with varible inside the query in one session
> it's
> replan each time
So if I run function 1 with varible inside the query in one session it's
replan each time.
But if whant to teling postgres do not doing this, what shoud i do?
We have more than 1 runs in one session with varible inside sql. And
have big performance problem in 9.2 and 9.3.
Here is my t
2013/8/23 Tom Lane
> Pavel Stehule writes:
> > please, can you send a self explained test
> > this issue should be fixed, and we need a examples.
>
> We already had a perfectly good example at the beginning of this thread.
> What's missing is a decision on how we ought to approximate the cost of
On 24/08/2013 21:16, Tom Lane wrote:
Marc Cousin writes:
On 23/08/2013 23:55, Tom Lane wrote:
My previous suggestion was to estimate planning cost as
10 * (length(plan->rangetable) + 1)
but on reflection it ought to be scaled by one of the cpu cost constants,
so perhaps
1000 * cpu_operator_cos
Marc Cousin writes:
> On 23/08/2013 23:55, Tom Lane wrote:
>> My previous suggestion was to estimate planning cost as
>> 10 * (length(plan->rangetable) + 1)
>> but on reflection it ought to be scaled by one of the cpu cost constants,
>> so perhaps
>> 1000 * cpu_operator_cost * (length(plan->ranget
On 23/08/2013 23:55, Tom Lane wrote:
Pavel Stehule writes:
please, can you send a self explained test
this issue should be fixed, and we need a examples.
We already had a perfectly good example at the beginning of this thread.
What's missing is a decision on how we ought to approximate the cos
Pavel Stehule writes:
> please, can you send a self explained test
> this issue should be fixed, and we need a examples.
We already had a perfectly good example at the beginning of this thread.
What's missing is a decision on how we ought to approximate the cost of
planning (relative to execution
2013/8/23 Fábio Telles Rodriguez
>
> It just inserts nb records in a loop in 4 different maneers:
>> - Directly in an int field
>> - Then in a numeric field (that's where we're having problems)
>> - Then in the same numeric field, but trying a cast (it doesn't change a
>> thing)
>> - Then tries w
> It just inserts nb records in a loop in 4 different maneers:
> - Directly in an int field
> - Then in a numeric field (that's where we're having problems)
> - Then in the same numeric field, but trying a cast (it doesn't change a
> thing)
> - Then tries with an intermediary temp variable of numer
On Wednesday, July 24, 2013 11:38 AM Amit Kapila wrote:
> On Wednesday, July 24, 2013 4:23 AM Tom Lane wrote:
> > I wrote:
> > > Marc Cousin writes:
> > >> The example below is of course extremely simplified, and obviously
> > not
> > >> what we are really doing in the database, but it exhibits th
On Wednesday, July 24, 2013 4:23 AM Tom Lane wrote:
> I wrote:
> > Marc Cousin writes:
> >> The example below is of course extremely simplified, and obviously
> not
> >> what we are really doing in the database, but it exhibits the
> slowdown
> >> between 9.1.9 and 9.2.4.
>
> > Hm. Some experime
I wrote:
> Marc Cousin writes:
>> The example below is of course extremely simplified, and obviously not
>> what we are really doing in the database, but it exhibits the slowdown
>> between 9.1.9 and 9.2.4.
> Hm. Some experimentation shows that the plan cache is failing to switch
> to a generic
Marc Cousin writes:
> The example below is of course extremely simplified, and obviously not
> what we are really doing in the database, but it exhibits the slowdown
> between 9.1.9 and 9.2.4.
Hm. Some experimentation shows that the plan cache is failing to switch
to a generic plan, but I'm not
Hi,
I've been trying to diagnose a severe performance regression we've been
having in one of our plpgsql procedures.
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
So here is t
16 matches
Mail list logo
