> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin
> Sent: 4. maí 2004 17:18
> To: [EMAIL PROTECTED]
> Subject: [GENERAL] Embedded SQL inherently faster than others?
>
>
> Hello,
>
> I've read when using embedded sql with an Oracle database,
It may be added to the Mark's points bellow that PHP has more libraries in
the out of the box setup (like regular expressions) but PHP is interpreted
(right?) while JSP is compiled: when I was making decision I have chosen JSP
because of "compiled" criteria: I do like the idea to catch as many bugs
A few question regarding PostgreSQL handling of queries:
- Is each query submitted parsed and planned even if it is identical to a
query submitted before?
For example, 10 queries "select * from animals where id=:b1" with possibly
different bind variable :b1 values will be fully processed (parsed
> On Behalf Of Cott Lang
> It seems to me that the lack of point-in-time recovery is a
> much bigger roadblock against big users. :(
Meaning incremental (hot)-backups?
Or as protection against DROP/TRUNCATE/DELETE ALL TABLE/SCHEMA/DATABASE?
With a WAL it should be doable in some 7.x version, al
This was probably asked n-times but still:
Is there any way to end (commit/rollback) a transaction inside a stored
function?
(The reason why it is good to commit/rollback in a stored procedure is that
in C/S environment it is not uncommon to have a dead client holding
locks(unfinished transactio
I am currently evaluating all open source databases and possibly my fresh
opinion will be of interest.
I went over documentation and setup of Firebird, MySQL and PostgreSql and
here is "perception"(to get better understanding one has to run thing for
quite a while):
As for "user friendly" image:
> On heavily used databases (over 100,000 transactions an
> hour), vacuum is
> a killer
That's about 27 tx/second - not so many, for some tasks at least.
If VACUUM is rather a killer
- are any plans from PostgreSQL to deal with that?
Thank you in advance,
Laimis
P.S. it's notable that eve
Any comments on multi-versioning problem:
As far as I understand from PG documentation, *CURRENTLY* VACUUM must be run
regulary, otherwise:
-Q. database will grow as fast as there are many DML going on it, won't it?
-Q. transaction ID may wrap - no doubt here.
-Q. Good news that VACUUM nowday
