Hello Jacky,
Do you whish to connect to PostgreSQL from Linux or Windows ?
Windows odbc driver: ftp://ring.asahi-net.or.jp/pub/misc/db/postgresql,
PHP 4.04 with PostgreSQL 7.1 drivers: http://rpms.arvin.dk/php/
Practically, you don't need ODBC drivers to connect from PHP to PostgreSQL.
Also,
mlw [EMAIL PROTECTED] writes:
Hmm ... given that ftss refers to external files, is it a good idea to
mark it cachable?
This I don't understand. What is the lifetime of a value that iscacheable?
Forever. cachable says it's OK to reduce func(constant) to constant
on sight. Right now it's not
On Sat, 19 May 2001, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think what we should probably do is make IN better and use that or then
support =ANY(=SOME)/=ALL on such things. I think =ANY would be easy
since IN is defined in terms of it in the spec.
And in our code
Hm. On the other hand, relying on WAL for undo means you cannot drop
old WAL segments that contain records for any open transaction. We've
already seen several complaints that the WAL logs grow unmanageably huge
when there is a long-running transaction, and I think we'll see a lot
more.
Vadim Mikheev [EMAIL PROTECTED] writes:
1. Space reclamation via UNDO doesn't excite me a whole lot, if we can
make lightweight VACUUM work well.
Sorry, but I'm going to consider background vacuum as temporary solution
only. As I've already pointed, original PG authors finally became
On Sun, 20 May 2001, Don Baccus wrote:
At 10:55 AM 5/20/01 -0700, Stephan Szabo wrote:
Can the IN always get written as a
join and is it always better to do so?
Nope:
...
A better question, I guess, is if it is always better to write
it as a join if the left hand operand is a table
1. Space reclamation via UNDO doesn't excite me a whole lot, if we can
make lightweight VACUUM work well.
Sorry, but I'm going to consider background vacuum as temporary solution
only. As I've already pointed, original PG authors finally became
disillusioned with the same approach.
As long as you're fixing bugs in pgindent, here are some more follies
exhibited by the most recent pgindent run. Some of these bugs have
been there for awhile, but at least one (the removal of space before
a same-line comment) seems to be new as of the most recent run.
The examples are all
Were you going to use WAL to get free space from old copies too?
Considerable approach.
Vadim, I think I am missing something. You mentioned UNDO would be used
for these cases and I don't understand the purpose of adding what would
seem to be a pretty complex capability:
Yeh, we already
Vadim Mikheev [EMAIL PROTECTED] writes:
Really?! Once again: WAL records give you *physical* address of tuples
(both heap and index ones!) to be removed and size of log to read
records from is not comparable with size of data files.
You sure? With our current approach of dumping data pages
On Sun, 20 May 2001, Vadim Mikheev wrote:
1. Space reclamation via UNDO doesn't excite me a whole lot, if we can
make lightweight VACUUM work well.
Sorry, but I'm going to consider background vacuum as temporary solution
only. As I've already pointed, original PG authors finally
The Hermit Hacker [EMAIL PROTECTED] writes:
If its an experiment, shouldn't it be done outside of the main source
tree, with adequate testing in a high load situation, with a patch
released to the community for further testing/comments, before it is added
to the source tree?
Mebbe we
Really?! Once again: WAL records give you *physical* address of tuples
(both heap and index ones!) to be removed and size of log to read
records from is not comparable with size of data files.
You sure? With our current approach of dumping data pages into the WAL
on first change since
If its an experiment, shouldn't it be done outside of the main source
tree, with adequate testing in a high load situation, with a patch
released to the community for further testing/comments, before it is added
to the source tree? From reading Vadim's comment above (re:
pre-Postgres95),
Seriously, I don't think that my proposed changes need be treated with
quite that much suspicion. The only part that is really intrusive is
Agreed. I fight for UNDO, not against background vacuum -:)
the shared-memory free-heap-space-management change. But AFAICT that
will be a necessary
Vadim Mikheev [EMAIL PROTECTED] writes:
Unfortunately, I think that we'll need in on-disk FSM and that FSM is
actually the most complex thing to do in space reclamation project.
I hope we can avoid on-disk FSM. Seems to me that that would create
problems both for performance (lots of extra
16 matches
Mail list logo
