From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | David Olbersen <dave(at)slickness(dot)org> |
Cc: | Gerald Gutierrez <pozix(at)home(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Temp Tables & Connection Pooling |
Date: | 2001-03-03 15:32:07 |
Message-ID: | 3AA10E77.B63D172B@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gerald Gutierrez | 2001-03-03 15:43:24 | Re: Temp Tables & Connection Pooling |
Previous Message | Richard Huxton | 2001-03-03 15:13:25 | Re: Insert into VIEW ??? |