On Mon, Jul 12, 2010 at 07:46:30PM +0200, Pavel Stehule wrote:
> 2010/7/12 Josip Rodin :
> > On Mon, Jul 12, 2010 at 04:38:48PM +0200, Pavel Stehule wrote:
> >> 2010/7/12 Josip Rodin :
> >> > On Mon, Jul 12, 2010 at 02:06:43PM +0800, Craig Ringer wrote:
> >> >> Meh, personally I'll stick to the goo
2010/7/12 Josip Rodin :
> On Mon, Jul 12, 2010 at 04:38:48PM +0200, Pavel Stehule wrote:
>> 2010/7/12 Josip Rodin :
>> > On Mon, Jul 12, 2010 at 02:06:43PM +0800, Craig Ringer wrote:
>> >> Meh, personally I'll stick to the good old profiling methods "is it fast
>> >> enough", "\timing", and "explai
On Mon, Jul 12, 2010 at 04:38:48PM +0200, Pavel Stehule wrote:
> 2010/7/12 Josip Rodin :
> > On Mon, Jul 12, 2010 at 02:06:43PM +0800, Craig Ringer wrote:
> >> Meh, personally I'll stick to the good old profiling methods "is it fast
> >> enough", "\timing", and "explain analyze".
> >
> > I agree. S
2010/7/12 Josip Rodin :
> On Mon, Jul 12, 2010 at 02:06:43PM +0800, Craig Ringer wrote:
>> Meh, personally I'll stick to the good old profiling methods "is it fast
>> enough", "\timing", and "explain analyze".
>
> I agree. Some hint could be included in 'explain analyze' output, maybe just
> to sep
On Mon, Jul 12, 2010 at 02:06:43PM +0800, Craig Ringer wrote:
> Meh, personally I'll stick to the good old profiling methods "is it fast
> enough", "\timing", and "explain analyze".
I agree. Some hint could be included in 'explain analyze' output, maybe just
to separate the timings for things th
On Mon, Jul 12, 2010 at 7:06 AM, Craig Ringer
wrote:
> It seems like a profiler, which is designed to filter and organize the
> collected data, and which can be attached only to specific functions that
> you want to know about, might be a better job. As there's already a PL/PgSQL
> debugger, some
2010/7/12 Craig Ringer :
> 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)
>>
>> i
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
Hello
2010/7/10 Tom Lane :
> Craig Ringer writes:
>> Your problem boils down to the fact that PL/PgSQL function calls are
>> expensive. PL/PgSQL is good for complex work, but bad for wrapping up
>> simple expressions because setting up / tearing down the function call
>> context is so expensive.
Craig Ringer writes:
> Your problem boils down to the fact that PL/PgSQL function calls are
> expensive. PL/PgSQL is good for complex work, but bad for wrapping up
> simple expressions because setting up / tearing down the function call
> context is so expensive.
Yes. What's actually the most ex
This may need to be made more obvious in the documentation...
Having both SQL and PL/PgSQL languages is one of those things that is different
enough from other database systems that many people will not expect and may not
notice it unless it is pointed out explicitly and prominently.
On Jul 10,
On 09/07/10 22:26, Josip Rodin wrote:
> db=# explain analyze select issuperuser(id) from users;
> QUERY PLAN
>
> Seq Scan on users (cost=0
13 matches
Mail list logo
