On Wed, 14 Mar 2007 18:50:27 +, [EMAIL PROTECTED] (Ashley
Moran) wrote:
in <[EMAIL PROTECTED]>
>It's more complicated than that. What we need to do is something
>along the lines of:
>
>results = SELECT * FROM foo();
>DELETE FROM results WHERE (some condition involving results);
>some_valu
On 15 Mar 2007, at 00:21, Tom Lane wrote:
Temp tables stay in RAM until they are bigger than temp_buffers.
If you
need them to be big and quick, maybe it would be appropriate to use
indexes (note these count towards temp_buffers), ANALYZE, etc.
You do need to realize that creation of a tem
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ashley Moran wrote:
>> Also I'm unsure how the use of temporary tables will affect the
>> running of the query. This function will be called up to 400 times
>> by a wrapping function that needs to complete quickly (relatively -
>> the calculations
Ashley Moran wrote:
>
> On Mar 14, 2007, at 7:25 pm, Tom Lane wrote:
> >Sure: use a table. What was the objection to temp tables exactly?
>
> My boss is under the impression that calling the procedure twice on
> the same connection creates a name conflict for the temporary table.
>
> Also I'm
> Sorry my sheer ignorance here. I have already written a working, fully
> tested - albeit unoptimised - implementation of this algorithm in Ruby,
> accessible as a basic (HTTP GET) web service. However, a developer here
> believes that the overhead of an HTTP connection over our gigabit LAN
> w
On Mar 14, 2007, at 7:25 pm, Tom Lane wrote:
Sure: use a table. What was the objection to temp tables exactly?
My boss is under the impression that calling the procedure twice on
the same connection creates a name conflict for the temporary table.
Also I'm unsure how the use of temporary
Ashley Moran wrote:
It fetches about 20 rows from a table of approx 4 million, then it
needs to do further calculations to narrow them down further.
Previously we have only written database code for SQL Server, and
there we would use a table variable. Apparently temporary tables are
not equi
Ashley Moran <[EMAIL PROTECTED]> writes:
> ... All of which is easy with table variable, but I can't see how to
> translate it to PL/pgsql. Is there any way to manipulate result sets
> in a set-based manner like this?
Sure: use a table. What was the objection to temp tables exactly?
Ashley Moran <[EMAIL PROTECTED]> schrieb:
>
> On Mar 14, 2007, at 6:02 pm, Andreas Kretschmer wrote:
> >select * from .
> >For instance, if your SRF-function is called foo(), do:
> >select * from foo();
>
>
> Andreas,
>
> It's more complicated than that. What we need to do is something along
On Mar 14, 2007, at 6:02 pm, Andreas Kretschmer wrote:
select * from .
For instance, if your SRF-function is called foo(), do:
select * from foo();
Andreas,
It's more complicated than that. What we need to do is something
along the lines of:
results = SELECT * FROM foo();
DELETE FROM
Ashley Moran <[EMAIL PROTECTED]> schrieb:
> The closest I've come from reading the docs is functions that return
> SETOF. However I can't see any way to query the result set like a table.
Right.
> Can anyone offer any hints/links?
select * from .
For instance, if your SRF-function is call
Hi
I'm passing this on second hand so forgive me if I'm a bit vague...
My boss is trying to write a function in PL/pgsql that manipulates a
small, temporary set of data. It fetches about 20 rows from a table
of approx 4 million, then it needs to do further calculations to
narrow them down
12 matches
Mail list logo
