I've got a process that every minute or so selects some data from a number of
tables. At the minute i dump this into a normal table, where i do some more
processing with it before truncating the table and starting again.. I don't
have any indexes on the temporary table but have thought about add
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> If you need some procedural logic (if-then-else stuff)
Yes
> then you'd need
> to go over to plpgsql, which would be a bit of a pain because its habit
> of caching query plans doesn't play nice with temp tables.
Going to plpgsql is fine. What I'm tryin
ow <[EMAIL PROTECTED]> writes:
> We are considering moving some reports from *** to Postgres. Our reports are
> written as stored procs in Transact-SQL and usually have the following
> structure:
> ...
> How would one rewrite the above logic in Postgresql?
If that's all you have to do, then SQL-la
Hi,
We are considering moving some reports from *** to Postgres. Our reports are
written as stored procs in Transact-SQL and usually have the following
structure:
CREATE PROCEDURE someReportProc AS
/* Purpose: Creates a report based on Table1.
*
* Overview of what will be done:
* 1) create a
Thanks, Jim. I'll give it a try.
On Tue, 2006-10-10 at 21:11 -0500, Jim C. Nasby wrote:
> On Tue, Oct 10, 2006 at 03:21:36PM -0400, [EMAIL PROTECTED] wrote:
> > Everyone,
> >
> > I've written a function (language = sql) which uses a temporary table to
> > simplify the process; however, when I g
On Tue, Oct 10, 2006 at 03:21:36PM -0400, [EMAIL PROTECTED] wrote:
> Everyone,
>
> I've written a function (language = sql) which uses a temporary table to
> simplify the process; however, when I go to load the function I get:
>
> /var/lib/pgsql$cat thm.sql | psql test
> ERROR: relation "lost_b
Everyone,
I've written a function (language = sql) which uses a temporary table to
simplify the process; however, when I go to load the function I get:
/var/lib/pgsql$cat thm.sql | psql test
ERROR: relation "lost_bus" does not exist
where "lost_bus" is the name of my temp table. The function
Lex Berezhny wrote:
hi,
I have a plpgsql procedure that needs to create a temporary table, use
it as a stack internally, and then disgard it when the procedure exits.
What are the recommendations or solutions on using temporary tables
inside functions on a per call basis?
thanks a lot,
I
You need to use EXECUTE. See the FAQ, item 4.26.
---
Lex Berezhny wrote:
> hi,
>
> I have a plpgsql procedure that needs to create a temporary table, use
> it as a stack internally, and then disgard it when the procedure e
hi,
I have a plpgsql procedure that needs to create a temporary table, use
it as a stack internally, and then disgard it when the procedure exits.
This works great if I only call this procedure ONCE per session. Calling
it a second time within the same session produces:
WARNING: Error occurred
(Maybe this thread is dead now, but here goes anyway)
Suggestion: have an environment variable or a PostgreSQL parameter to
indicate where to write the temp-table to. This way, you could easily direct
it to a RAM disk (if small enough) or to a drive other than your main
database. Default could be
Paul McGarry <[EMAIL PROTECTED]> writes:
> Can I avoid having the temp table written to disk
Not at present --- temp tables are not different from real tables,
except for some naming shenanigans. So creation of a temp table will
involve some disk hits.
Do you really *need* a temp table, as oppo
Howdy,
> If the temp table doesn't fit in memory, we will have to put it in
> backing store somewhere, and a disk is the logical place, right? I
> don't see a huge advantage of putting it in memory. We could prevent
> WAL writes for temp tables. That would help.
Yes, if it won't fit in memory
> Hi Tom,
>
> Thanks for your response, enlightening as always.
>
> > Not at present --- temp tables are not different from real tables,
> > except for some naming shenanigans. So creation of a temp table will
> > involve some disk hits.
>
> Ok, would it be a good idea to modify that for the f
Hi Tom,
Thanks for your response, enlightening as always.
> Not at present --- temp tables are not different from real tables,
> except for some naming shenanigans. So creation of a temp table will
> involve some disk hits.
Ok, would it be a good idea to modify that for the future? Given that
Hi,
I have an application where I am using fulltextindex to
create a searchable index for a table and wish to return
pages of results, ranked in order of relevance. So for any
particular page view I need to know:
a) Total number of results relevant to search (so I can display
page [1] 2 3 4 5
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 tem
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 temp
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 sess
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 would
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 th
21 matches
Mail list logo