Thread: Temp Tables & Connection Pooling
I use PostgreSQL via a connection pooling mechanism, whether it be J2EE or PHP. I've been able to achieve good performance this way, and it has been good to me. Recently I wanted to implement Dijkstra's algorithm as a stored procedure, and finding that PL/PGSQL cannot return record sets, I thought about using a temporary table for the results. If tempoary tables are session-specific, however, then wouldn't connection pooling make it unusable since the table might "disappear" from one query to the next? What are alternative approaches to implementing Dijkstra's algorithm inside the database? I'd appreciate any insights. Gerald.
On Fri, 2 Mar 2001, Gerald Gutierrez wrote: ->Recently I wanted to implement Dijkstra's algorithm as a stored procedure, ->and finding that PL/PGSQL cannot return record sets, I thought about using ->a temporary table for the results. If tempoary tables are session-specific, ->however, then wouldn't connection pooling make it unusable since the table ->might "disappear" from one query to the next? What are alternative ->approaches to implementing Dijkstra's algorithm inside the database? <newbie> Wouldn't a VIEW do what you want? </newbie> -- Dave
David Olbersen wrote: > > On Fri, 2 Mar 2001, Gerald Gutierrez wrote: > > ->Recently I wanted to implement Dijkstra's algorithm as a stored procedure, > ->and finding that PL/PGSQL cannot return record sets, I thought about using > ->a temporary table for the results. If tempoary tables are session-specific, > ->however, then wouldn't connection pooling make it unusable since the table > ->might "disappear" from one query to the next? What are alternative > ->approaches to implementing Dijkstra's algorithm inside the database? > > <newbie> > Wouldn't a VIEW do what you want? > </newbie> > > -- Dave Presumably Gerald's after speed here - IIRC Dijkstra's is shortest path finder, so probably not cheap. I was thinking about the temp table problem the other day, and the best I could come up with involved creating a higher-level connection (application-level session basically). You'd create a table mytempNNN (where NNN is a unique number to identify your user's session) and add a line to a tracking table (NNN,now()) Every time you use mytempNNN update the tracking table's time and run a separate reaper process to kill anything not used for 15 minutes (or whatever). You should be able to automate this to a degree with triggers etc. - Richard Huxton
At 12:48 PM 3/2/2001 -0800, David Olbersen wrote: >On Fri, 2 Mar 2001, Gerald Gutierrez wrote: > >->Recently I wanted to implement Dijkstra's algorithm as a stored procedure, >->and finding that PL/PGSQL cannot return record sets, I thought about using >->a temporary table for the results. If tempoary tables are session-specific, >->however, then wouldn't connection pooling make it unusable since the table >->might "disappear" from one query to the next? What are alternative >->approaches to implementing Dijkstra's algorithm inside the database? > ><newbie> >Wouldn't a VIEW do what you want? ></newbie> No it wouldn't. Executing Dijkstra would involve executing iterative logic on multiple tables and storing intermediate results in a form that can be returned to the user but does not affect the actual persistent table schema (e.g. a record set, or a temporary table). A view is used to provide a simplified or alternative way of looking at a set of data, and cannot cannot generally multi-step operation that data prior to returning to the user.
Gerald Gutierrez wrote: > At 12:48 PM 3/2/2001 -0800, David Olbersen wrote: > >On Fri, 2 Mar 2001, Gerald Gutierrez wrote: > > > >->Recently I wanted to implement Dijkstra's algorithm as a stored procedure, > >->and finding that PL/PGSQL cannot return record sets, I thought about using > >->a temporary table for the results. If tempoary tables are session-specific, > >->however, then wouldn't connection pooling make it unusable since the table > >->might "disappear" from one query to the next? What are alternative > >->approaches to implementing Dijkstra's algorithm inside the database? > > > ><newbie> > >Wouldn't a VIEW do what you want? > ></newbie> > > No it wouldn't. Executing Dijkstra would involve executing iterative logic > on multiple tables and storing intermediate results in a form that can be > returned to the user but does not affect the actual persistent table schema > (e.g. a record set, or a temporary table). A view is used to provide a > simplified or alternative way of looking at a set of data, and cannot > cannot generally multi-step operation that data prior to returning to the user. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org This looks like a case for a persistent table where the function would write the data, along with some kind of session identifier, which would be returned from the function. Then your could go back to that table with that sessionid and find what you need. It is kludgey because it has the potential to leave stale data lying around, you will have to write all kinds of housekeeping code around it.