I was very open with the developers and said they could have implemented the same logical solution in their language of choice, I prefer PL/SQL.

To @Michael OShea’s question, yes, a table function is any function that returns a collection.

The benefits of a PIPELINED table function are that the client processing of rows from the function can be overlapped with the function’s runtime, so the application can start doing something useful instead of waiting for the function to complete. I believe that the true “power” of PIPELINED functions are that they can be used in conjunction with parallelization which can be a real performance boost–however, I don’t say that confidently as I haven’t worked with them enough to know all those details. I requested that Steven follow up here when he has time, so hopefully we’ll get some more expert input soon.

I was a bit surprised by the numbers as well and that’s why I decided to come out of blog-hiding and write it up. I suppose some of the “less interesting” results would have made good blog material too, but I don’t seem to be able to form blogging habits very well. Anyway, thanks for your comments and I would love to hear how your testing goes–especially if the results are different than mine.

Regardless, I’m intrigued by your numbers and may start doing some performance numbers between a Pipelined table-function (what I had the developers implement) and a regular table-functions.

I didn’t get in to the reasons why the customer had originally used PF, but for them, I don’t think it was as much about the processing time (since the complete record set was only about 30-40 rows). In this case, they had several different queries that needed to run, but they wouldn’t know which queries to run until runtime. So, it was relatively easy for them to just run a query and PIPE the rows out at runtime. For my test, I just added those rows to a collection and then returned the whole collection at the end.

Either way, I found this interesting and I’m grateful that you stopped by to comment!

I am glad to see you talking about pipelined functions; it is a feature of PL/SQL that is unfamiliar to most developers.

One thing I have noticed from my trainings regarding pipelined functions, however, is that PL/SQL developers seem to use them when what they really mean to use is a table function.

A table function is a function that can be called in the FROM clause of a query, and that fact offers all sorts of tantalizing possibilities. Generally, you can hide complex transformations inside a function’s body and expose the result as nothing more than rows and columns in a query.

A pipelined function is a specialized form of the table function that returns data back to the calling query (it must be called inside a query) while the function is still executing.

A pipelined function will not reduce the total elapsed time of a function’s execution; in fact, in my experience non-pipelined table functions often perform a little bit faster than their pipelined equivalent.

The special thing about the PF is that the calling query can start using data from the function before it has processed all its data – and this means that you can reduce the perceived elapsed time to the user (a webpage built around a PF can display the first 100 rows while the next 10,000 are being retrieved) as well as parallelize execution of table functions.

So…don’t use a pipelined function unless you actually need its special properties!

Steven Feuerstein
http://www.ToadWorld.com/SF