SETOF performance
От | Jeff |
---|---|
Тема | SETOF performance |
Дата | |
Msg-id | 49B1B198-871E-11D8-B8C1-000393D1F76E@torgo.978.org обсуждение исходный текст |
Ответы |
Re: SETOF performance
|
Список | pgsql-performance |
I think it was on this list - someone posted a message about SETOF being slower. Tom replied saying it was because it needed to create an on-disk tuplestore. I was just looking for some clarification - a SETOF function will always write the reslting tuples to disk (Not buffering in say a sort_mem sized buffer)? I think if that is the case I may need to go back and change some stuff around. I have a procedure that I broke out a bit to make life easier. Basically it goes for v_row in select blah from function_that_gets_data_from_some_cache(....) rowcount := rowcount + 1; return next v_row; end for; if rowcount = 0 then [same thing, but we call some_function_that_creates_data_for_cache] end if; Doing it this way means I avoid having to deal with it in the client and I also avoid having a giant stored procedure. (I like short & sweet things) What I've found for timings is this: select * from function_that_gets_data_from_some_cache() runs around 1.8 ms but select * from the_top_level_function() runs around 4.2ms (Yes, I know 4.2 ms is fast, but that is not the point). could this overhead be related to the SETOF tuplestores? Might it be better to use refcursor or something or bite the bullet and live with a giant procedure? -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
В списке pgsql-performance по дате отправления: