From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Gary Doades <gpd(at)gpdnet(dot)co(dot)uk> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL vs. Oracle vs. Microsoft |
Date: | 2005-01-11 00:04:37 |
Message-ID: | 41E31815.4030908@fastcrypt.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ok, so one use case is to select a large number of rows and do some
non-trivial operation on them.
I can see where getting the rows inside the server process ( ie some
procedural language ) thereby reducing the round trip overhead would be
beneficial. However how do you deal with the lack of control ? For
instance what happens if you run out of memory while doing this ? I'm
not sure about other DB'S but if you crash the procedural language
inside postgres you will bring the server down.
It would seem to me that any non-trivial operation would be better
handled outside the server process, even if it costs you the round trip.
Dave
Gary Doades wrote:
> Dave Cramer wrote:
>
>> I'm curious, why do you think that's serious ? What do you really
>> expect to do in the stored procedure ? Anything of consequence will
>> seriously degrade performance if you select it in say a million rows.
>>
>
> I'm not sure what you mean by "select it in a million rows". I would
> expect to write a procedure within the database engine to select a
> million rows, process them and return the result to the client. Very
> efficient.
>
> Cheers,
> Gary.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2005-01-11 01:24:47 | Re: PostgreSQL vs. Oracle vs. Microsoft |
Previous Message | Christopher Browne | 2005-01-10 23:57:25 | Re: PostgreSQL vs. Oracle vs. Microsoft |