Re: simple functions, huge overhead, no cache
От | Pavel Stehule |
---|---|
Тема | Re: simple functions, huge overhead, no cache |
Дата | |
Msg-id | AANLkTikSCsAMdkPE-uti4K7s204SXhOd2QxIe1XndEeA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: simple functions, huge overhead, no cache (Josip Rodin <joy@entuzijast.net>) |
Ответы |
Re: simple functions, huge overhead, no cache
|
Список | pgsql-general |
2010/7/12 Josip Rodin <joy@entuzijast.net>: > On Mon, Jul 12, 2010 at 04:38:48PM +0200, Pavel Stehule wrote: >> 2010/7/12 Josip Rodin <joy@entuzijast.net>: >> > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
В списке pgsql-general по дате отправления: