2010/7/12 Josip Rodin <joy@xxxxxxxxxxxxxx>: > On Mon, Jul 12, 2010 at 04:38:48PM +0200, Pavel Stehule wrote: >> 2010/7/12 Josip Rodin <joy@xxxxxxxxxxxxxx>: >> > 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 that are well covered by the query plan >> > optimizer from those that aren't. I found this in a line like this: >> >> it is useles for functions - explain doesn't show lines of executed >> functions. Can you show some example of some more complex query. > > It doesn't have to show me any lines, but it could tell me which part of > the query is actually being optimized, and OTOH which part is simply being > executed N times unconditionally because it's a function that is marked as > volatile. That alone would be a reasonable improvement. this is different kinds of problems. You can have a very slow a immutable function or very fast volatile function. And with wrong function design your functions can be a 10 times slower. yeah - you can multiply it via wrong or good design with wrong or good stability flag. Regards Pavel Stehule > > -- > 2. That which causes joy or happiness. > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
