"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 e
> 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 necessa
> 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-Postgres9
> > 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 chang
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
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 aut
"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 p
> 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 alread
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 taken
> >> 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
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
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 o
On Sat, 19 May 2001, mlw wrote:
> Stephan Szabo wrote:
> >
> > (Machine couldn't find mx record for mohawksoft, replying only
> > to list)
> >
> > On Sat, 19 May 2001, mlw wrote:
> >
> > > Sorry to gripe here. Don't get me wrong, I think Postgres is amazing, and I
> > > think all you guys do a
mlw <[EMAIL PROTECTED]> writes:
> Am I out in left field here? Does anyone see this as a problem? I guess there
> should be three states to the lifetime of a functions return value?
There has been some talk of that, but nailing down exactly what the
semantics ought to be still needs more thought.
"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 becam
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
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, tr
17 matches
Mail list logo
