On Mon, 15 Apr 2002, Christopher Kings-Lynne wrote:
> > ...the OID and
> > the NULL bitfield) are not used; would it be possible to avoid
> > allocating these in this relations that don't use them?
>
> CREATE TABLE WITHOUT OIDS ...
As you can see from the schema I gave later in my message, that'
I'm about to commit your patches with a small fix.
--
Tatsuo Ishii
From: Joe Conway <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] unknownin/out patch (was [HACKERS] PQescapeBytea is
Date: Mon, 08 Apr 2002 22:57:47 -0700
Message-ID: <[EMAIL PROTECTED]>
> Joe Conway wrote:
> > Tatsuo Ishii wrote:
> >
> As you can see from the schema I gave later in my message, that's
> exactly what I did. But does this actually avoid allocating the
> space in the on-disk tuples? What part of the code deals with this?
> It looks to me like the four bytes for the OID are still allocated
> in the tuple, but not u
On Mon, 15 Apr 2002, Christopher Kings-Lynne wrote:
> OK, well now it depends on what kind of selects you're doing. Do you
> regularly select over a certain subset of the data, in which case using
> partial indices might give you significant speedup.
I believe from the information I've been giv
>b) In fact, at times I don't need that data integrity. I'm
> prefectly
>happy to risk the loss of a table during import, if it
> lets me do the
>import more quickly, especially if I'm taking the database off line
>to do the import anyway. MS SQL server in fact allo
On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
> BTW, instead of:
>
> CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
>
> do:
>
> ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
I am sorry, could you please elaborate more on the difference?
--
Denis
---(e
> On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
> > BTW, instead of:
> >
> > CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
> >
> > do:
> >
> > ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
>
> I am sorry, could you please elaborate more on the difference?
They have the same _e
On Monday 15 April 2002 05:15, Christopher Kings-Lynne wrote:
> > On Monday 15 April 2002 03:53, Christopher Kings-Lynne wrote:
> > > BTW, instead of:
> > >
> > > CREATE UNIQUE INDEX bigone_pkey ON bigone (rec_no);
> > >
> > > do:
> > >
> > > ALTER TABLE bigone ADD PRIMARY KEY(rec_no);
> >
> > I a
>"Mario Weilguni" <[EMAIL PROTECTED]> writes:
>> And I did not find out how I can detect the large object
>> chunksize, either from getting it from the headers (include
>> "storage/large_object.h" did not work)
>
>Why not?
>
>Still, it might make sense to move the LOBLKSIZE definition into
>pg_con
On Mon, 15 Apr 2002, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I recall that this was the behavior we agreed we wanted. IMHO, it would
> > be conditional on the INSERT ... VALUES (DEFAULT) capability being
> > provided. I'm not sure if that is there yet.
>
> That is the
I was just being asked if we are working on deletion of attributes in an
existing table. Something like ALTER TABLE foo DROP COLUMN bar. Is
anyone working on this, or are there design problems with it?
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux!
> Yes, I know. I mean how does this affect performance? How this can change
> planner decision? Does it have any effect except cosmetical one?
Only cosmetic. In the example he gave, he wanted a primary key, so I showed
him how to make one properly.
Chris
---(end of bro
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> getTables(): SELECT (for PRIMARY KEY) failed on table config_2002_03_02.
> Explanation from backend: ERROR: dtoi4: integer out of range
> Any idea how to fix this? This is on 7.1.3. Will the 7.2 pg_dump handle this
> database?
Yes.
> Hannu Krosing wrote:
> >
> > Have you found out _what_ exaclty is patented ?
> >
> > Is it just his concrete implementation of "UB-Tree" or something
> > broader, like using one multi-dimensional index instead of multiple
> > one-dimensional ones ?
(I know it is OT, please reply in private, I
I while ago I used xbase2pg and pg2xbase.
You should be able to find it on the net.
[EMAIL PROTECTED] wrote:
>
> Hannu Krosing wrote:
> >
> > Have you found out _what_ exaclty is patented ?
> >
> > Is it just his concrete implementation of "UB-Tree" or something
> > broader, like using one multi
On Sun, 2002-04-14 at 08:48, Lamar Owen wrote:
>
> Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement over
> RHL 7.2, and I personally recommend it, as KDE 3 is worth the upgrade, even
> to a beta.
Is the 7.2.93 (skipjack) public beta an improvement in raw postgresql
perf
On Fri, 12 Apr 2002 13:28:34 -0400
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> pg_dumping a table having a primary key yields commands like
>
> --
> -- TOC Entry ID 2 (OID 139812)
> --
> -- Name: table1 Type: TABLE Owner: postgres
> --
>
> CREATE TABLE "table1" (
> "column10" character varying
On Wed, 10 Apr 2002 [EMAIL PROTECTED] wrote:
> Anyway, this is once more a good example of the danger of software patents
> - you know what to reply when people say "software patents promote
> innovation"
We (AEL, an association promoting freedom in every sense) have just now
put on-line a pag
Hannu Krosing wrote:
>
> Have you found out _what_ exaclty is patented ?
>
> Is it just his concrete implementation of "UB-Tree" or something
> broader, like using one multi-dimensional index instead of multiple
> one-dimensional ones ?
(I know it is OT, please reply in private, I can summariz
Is PostgreSQL broken? Or is it FreeBSD?
--
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/36954
PostgreSQL does not currently check the results of mktime(). On a
border condition, mktime() fails and would populate invalid data
into the database.
Most other *NIX's see
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Mon, 15 Apr 2002, Christopher Kings-Lynne wrote:
>> CREATE TABLE WITHOUT OIDS ...
> As you can see from the schema I gave later in my message, that's
> exactly what I did. But does this actually avoid allocating the
> space in the on-disk tuples? What
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> * select octet_length(data) from pg_largeobject where loid=OIDOFOBJECT and pageno=0
This really should not work if you're not superuser. Right now it does,
but I think that's an oversight in the default permissions settings for
system tables. Anyon
And how about getting database internals via SQL-functions - e.g. getting BLCSIZE,
LOBBLCSIZE?
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 15. April 2002 16:32
An: Mario Weilguni
Cc: [EMAIL PROTECTED]
Betreff: Re: [HACKERS] Inefficient handling of
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Yes, I know. I mean how does this affect performance? How this can change
>> planner decision? Does it have any effect except cosmetical one?
> Only cosmetic. In the example he gave, he wanted a primary key, so I showed
> him how to make o
On Sun, 14 Apr 2002, Bruce Momjian wrote:
>
> Good question. I see the thread at:
>
>
>http://groups.google.com/groups?hl=en&threadm=Pine.LNX.4.30.0202262002040.685-10%40peter.localdomain&rnum=2&prev=/groups%3Fq%3Dcreate%2Boperator%2Bgroup:comp.databases.postgresql.*%26hl%3Den%26selm%
Tatsuo Ishii writes:
> > Whatever you do with this patch, remember that the USE_LOCALE symbol is
> > gone.
>
> I thought we have some way to tern off locale support at the configure
> time.
You do it at initdb time now.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end
After some fooling around with gram.y, I have come to the conclusion
that there's just no way to use a schema-qualified name for an operator
in an expression. I was hoping we might be able to write something like
operand1 schema.+ operand2
but I can't find any way to make this work withou
What would it take to make the array iterator functions a part of the
standard base? (contrib/array)
A number of people want this type of functionality (value = [ any
value of array ], and value = [ all values of array ] ).
The license needs to be changed (with authors permission), but other
tha
Awhile back I said:
> [EMAIL PROTECTED] (Neil Conway) writes:
>> In other words, when the insert statement on the view is transformed by
>> the rule, the "default value" columns are replaced by explicit NULL
>> values (which is the default value for the columns of the pseudo-table
>> created by CR
Tom Lane wrote:
>
> 1. Keep operators as database-wide objects, instead of putting them into
> namespaces. This seems a bit silly though: if the types and functions
> that underlie an operator are private to a namespace, shouldn't the
> operator be as well?
>
Not necessarily. One can still cr
Fernando Nasser <[EMAIL PROTECTED]> writes:
> If some types are really important and operators are desired, it can be
> coordinated with the DBA as operators would be a database wide resource.
> (This would be the case if indices extensions were involved anyway).
No, there isn't any particular re
On Mon, 15 Apr 2002 14:25:28 -0400
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Awhile back I said:
> > [EMAIL PROTECTED] (Neil Conway) writes:
> >> In other words, when the insert statement on the view is transformed by
> >> the rule, the "default value" columns are replaced by explicit NULL
> >> valu
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> What would it take to make the array iterator functions a part of the
> standard base? (contrib/array)
To me, the main problem with contrib/array is that it doesn't scale:
you need more C functions for every array datatype you want to support.
At the ve
Hi all,
I'm seeing this on a fresh build from CVS:
$ ./configure && make && make check
...
$ cd src/test/regress/tmp_check
$ ./install/tmp/pgsql/bin/postgres -D data regression
LOG: database system was shut down at 2002-04-15 15:03:58 EDT
LOG: checkpoint record is at 0/160368C
LOG: redo recor
> 2. Use a restricted, perhaps fixed search-path for searching for
> operators. For example, we might force the search path to have
> pg_catalog first even when this is not true for the table name
search
> path. But I'm not sure what an appropriate definition would be.
> A restricted search path
Hi,
I'm thinking of doing a patch to generate foo_fkey and foo_chk names for
fk's and checks. I know that this will make using DROP CONSTRAINT a whole
heck of a lot easier. There have also been a few people who've complained
on the list about all the foreign keys, etc.
I know Tom had some fea
Tom Lane wrote:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > * select octet_length(data) from pg_largeobject where loid=OIDOFOBJECT and pageno=0
>
> This really should not work if you're not superuser. Right now it does,
> but I think that's an oversight in the default permissions settings
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anyone object if I turn off public read access to
>> pg_largeobject?
> Please do whatever you can to tighten it up. I thought we needed to keep
> read access so people could get to their large objects, but maybe not.
Yeah, right afte
Tom Lane writes:
> After some fooling around with gram.y, I have come to the conclusion
> that there's just no way to use a schema-qualified name for an operator
> in an expression. I was hoping we might be able to write something like
> operand1 schema.+ operand2
> but I can't find any wa
Neil Conway <[EMAIL PROTECTED]> writes:
> POSTGRES backend interactive interface
> $Revision: 1.260 $ $Date: 2002/03/24 04:31:07 $
> backend> create table foo (c1 int);
> ERROR: invalid relation "foo"; system catalog modifications are currently disallowed
> backend> create schema x;
> backend>
Yes! Please do something with those unnamed constraints.
---
Christopher Kings-Lynne wrote:
> Hi,
>
> I'm thinking of doing a patch to generate foo_fkey and foo_chk names for
> fk's and checks. I know that this will make
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Peter, are you saying you don't want to require all columns to be
> > specified when INSERT doesn't list the columns?
>
> Yes, that's what I'm saying. Too much breakage and annoyance potential in
> that change.
OK, how about a NOTICE statin
Vince Vielhaber wrote:
> On Mon, 15 Apr 2002, Tom Lane wrote:
>
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > I recall that this was the behavior we agreed we wanted. IMHO, it would
> > > be conditional on the INSERT ... VALUES (DEFAULT) capability being
> > > provided. I'm not sure if
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We could make some sort of escape syntax, like
> op1 myschema.operator(+) op2
I thought a little bit about that ... the above syntax does not work
but it looks like we could do something along the lines of
op1 OPERATOR(myschema.+) op2
Bruce Momjian writes:
> OK, how about a NOTICE stating that the missing columns were filled in
> with defaults?
Please not.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I'm thinking of doing a patch to generate foo_fkey and foo_chk names for
> fk's and checks. I know that this will make using DROP CONSTRAINT a whole
> heck of a lot easier. There have also been a few people who've complained
> on the list a
Tom Lane writes:
> But: do you really want to see all dumped rules, defaults, etc in that
> style? Ugh... talk about loss of readability...
I imagine that pg_dump could be able to figure out that certain references
would be "local", so no explicit schema qualification is necessary.
Thus, the on
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I imagine that pg_dump could be able to figure out that certain references
> would be "local", so no explicit schema qualification is necessary.
Well, if it makes assumptions about the path then it can do that ... or
I guess it could explicitly set t
Neil Conway <[EMAIL PROTECTED]> writes:
> backend> create table foo (c1 int);
> ERROR: invalid relation "foo"; system catalog modifications are currently disallowed
I've committed a fix for this.
BTW, I dunno about other developers, but I never use standalone backends
for debugging. It's a lot
Fix applied. Thanks.
---
Bruce Momjian wrote:
>
> David, sorry you patch didn't make it into 7.2.X. That whole EINTR
> discussion was quite complicated so I am not surprised we missed it.
>
> The attached patch implemen
Fix applied.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The breakage will come when we lengthen NAMEDATALEN, which I plan to
> > tackle for 7.3. We will need to re-order the NOTIFY structure and pu
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I imagine that pg_dump could be able to figure out that certain references
> > would be "local", so no explicit schema qualification is necessary.
[snip]
> * Names in the current schema need be qualified only if they
W
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Names in the current schema need be qualified only if they
> What does the current schema mean ?
In this case, it means the one pg_dump is trying to dump.
regards, tom lane
---(end
> Whatever you do with this patch, remember that the USE_LOCALE symbol is
> gone.
Then the patches should be modified.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> Tatsuo,
>
> Yes, ant version 1.4.1 or later is required to build the driver
Then it should be noted somewhere in the docs. Also, that should be
noted in the "incompatibilty section" of the release note for 7.3.
--
Tatsuo Ishii
> see http://jakarta.apache.org/ant
>
> Dave
> On Sat, 2002-04-13
Tatsuo Ishii wrote:
> > Whatever you do with this patch, remember that the USE_LOCALE symbol is
> > gone.
>
> Then the patches should be modified.
Yes, I am not quite sure how to do that. I will research it unless
someone else lends a hand.
--
Bruce Momjian| http://
In my understanding, our consensus was enabling multibyte support by
default for 7.3. Any objection?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
On Mon, 15 Apr 2002, Tom Lane wrote:
> > I'm not looking for "runs a bit faster;" five percent either way
> > makes little difference to me. I'm looking for a five-fold performance
> > increase.
>
> You are not going to get it from this; where in the world did you get
> the notion that data integ
Curt Sampson wrote:
> On Mon, 15 Apr 2002, Tom Lane wrote:
>
> > > I'm not looking for "runs a bit faster;" five percent either way
> > > makes little difference to me. I'm looking for a five-fold performance
> > > increase.
> >
> > You are not going to get it from this; where in the world did yo
Bruce Momjian writes:
> Tatsuo Ishii wrote:
> > > Whatever you do with this patch, remember that the USE_LOCALE symbol is
> > > gone.
> >
> > Then the patches should be modified.
>
> Yes, I am not quite sure how to do that. I will research it unless
> someone else lends a hand.
Basically, you m
On Mon, 15 Apr 2002 21:44:26 -0400 (EDT)
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> In the old days, we created indexes
> only after the data was loaded, but when we added PRIMARY key, pg_dump
> was creating the table with PRIMARY key then loading it, meaning the
> table was being loaded while i
On Mon, 15 Apr 2002, Bruce Momjian wrote:
> Can you check your load and see if there is a PRIMARY key on the table
> at the time it is being loaded.
There is not. I create the table with a PRIMARY KEY declaration,
but I drop that index before doing the import, and do an ALTER
TABLE to re-add the
Tom Lane writes:
> What I'm now envisioning is that pg_dump will explicitly set
> set search_path = 'foo';
> when dumping or reloading schema foo.
I had imagined that pg_dump would emit commands such as this:
CREATE SCHEMA foo
CREATE TABLE bar ( ... )
CREATE otherthings
;
which is ho
Tatsuo Ishii writes:
> In my understanding, our consensus was enabling multibyte support by
> default for 7.3. Any objection?
It was my understanding (or if I was mistaken, then it is my suggestion)
that the build-time option would be removed altogether and certain
performance-critical places (i
According to POSIX -regex (7)-, standard character class are:
alnum digit punct
alpha graph space
blank lower upper
cntrl print xdigi
Many of that classes are different in different locales, a
...
> I don't really consider this a bug; at least, fixing it would imply not
> const-simplifying the result expressions of CASEs, which is a cure far
> worse than the disease IMHO. Does anyone think we *should* allow CASE
> to defeat const-simplification?
No. Constant-folding during parsing sho
> According to POSIX -regex (7)-, standard character class are:
>
> alnum digit punct
> alpha graph space
> blank lower upper
> cntrl print xdigi
>
> Many of that classes are different in diff
...
> OK, how about a NOTICE stating that the missing columns were filled in
> with defaults?
Yuck. There is a short path from that to rejecting the insert, but
printing the entire insert statement which would have been acceptable in
the error message ;)
- Thomas
> Actually I'm in favor of it. I have a proposal outstanding to require
> constraints to have names that are unique per-table, for consistency
> with triggers (already are that way) and rules (will become that way,
> rather than having globally unique names as now). AFAIR the only
> significant
> Is PostgreSQL broken? Or is it FreeBSD?
Both at most. FreeBSD at least ;)
The Posix definition for mktime() insists that the function return "-1"
if it has an error. Which also happens to correspond to 1 second earlier
than 1970-01-01, causing trouble for supporting *any* times before 1970.
P
Here is an email I sent to patches, minus the patch. I am sending to
hackers for comments.
---
>
> The following patch adds --maxindfuncparams to configure to allow you to
> more easily set the maximum number of function
On the note of NAMEDATALEN, a view in the INFORMATION_SCHEMA
definition is exactly 2 characters over the current limit.
ADMINISTRABLE_ROLE_AUTHORIZATIONS
Not that it's a great reason, but it isn't a bad one for increasing
the limit ;)
--
Rod Taylor
> Are we staying at 16 as the default? I pe
[ copied to hackers ]
> 1. I don't like the code that installs and removes ad-hoc
dependencies
> from relations to type Oid. On its own terms it's wrong (if it were
...
> explicit representation of pinning in the pg_depends table, perhaps
it
> would work to create a row claiming that "table 0 /
En Mon, 15 Apr 2002 23:19:45 -0400
"Rod Taylor" <[EMAIL PROTECTED]> escribió:
> On the note of NAMEDATALEN, a view in the INFORMATION_SCHEMA
> definition is exactly 2 characters over the current limit.
>
> ADMINISTRABLE_ROLE_AUTHORIZATIONS
>
> Not that it's a great reason, but it isn't a bad on
On Mon, 15 Apr 2002 23:34:04 -0400
"Alvaro Herrera" <[EMAIL PROTECTED]> wrote:
> En Mon, 15 Apr 2002 23:19:45 -0400
> "Rod Taylor" <[EMAIL PROTECTED]> escribió:
>
> > On the note of NAMEDATALEN, a view in the INFORMATION_SCHEMA
> > definition is exactly 2 characters over the current limit.
> >
>
Alvaro Herrera wrote:
> (Tom Lane says both SQL92 and SQL99 specify 128 as the maximun
> identifier length)
>
> Anyway, how does one measure the perfomance impact of such a change?
> By merely changing the constant definition, or also by actually using
> long identifiers? I can do that if it's of
> > Anyway, how does one measure the perfomance impact of such a change?
> > By merely changing the constant definition, or also by actually using
> > long identifiers? I can do that if it's of any help, for various values
> > perhaps.
>
> I think I would measure disk size change in a newly create
On Tue, 16 Apr 2002, Curt Sampson wrote:
[snip]
> What I'm thinking would be really cool would be to have an "offline"
> way of creating tables using a stand-alone program that would write
> the files at, one hopes, near disk speed.
Personally, I think there is some merit in this. Postgres can
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I don't think character classes are applicable for most mutibyte
> encodings. Maybe only the exeception is Unicode?
Maybe, and is the only one I need ;-)
>
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > >
> > > Basically, you manually preprocess
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I had imagined that pg_dump would emit commands such as this:
> CREATE SCHEMA foo
> CREATE TABLE bar ( ... )
> CREATE otherthings
> ;
> which is how I read the SQL standard. Are there plans to implement the
> CREATE SCHEMA command that way? I
Tom Lane writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > My vote is to set the default # of function args to some
> > reasonable default (32 sounds good), and leave it at that.
>
> Bear in mind that s/32/16/ gives you the exact state of the discussion
> when we raised the limit from 8 to 16
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> In my understanding, our consensus was enabling multibyte support by
> default for 7.3. Any objection?
Uh, was it? I don't recall that. Do we have any numbers on the
performance overhead?
regards, tom lane
The Firebird guys have gotten around to releasing 1.0. If you read this
front page spiel, you'll notice that they use MVCC, but with an overwriting
storage manager.
http://www.ibphoenix.com/ibp_act_db.html
The relevant extract:
"Multi-version concurrency control uses back versions of modified
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> How about this: We store the first 16 parameters in some fixed array for
> fast access like now, and when you have more than 16 then 17 and beyond
> get stored in some variable array in pg_proc.
<> What's this going to cost us in the function looku
On Tue, 16 Apr 2002, Gavin Sherry wrote:
> I don't see any straight forward way of modifying the code to allow a fast
> path directly to relationals on-disk. However, it should be possible to
> bypass locking, RI, MVCC etc with the use of a bootstrap-like tool.
That was my thought. I'm not askin
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > How about this: We store the first 16 parameters in some fixed array for
> > fast access like now, and when you have more than 16 then 17 and beyond
> > get stored in some variable array in pg_proc.
>
> <> What's this going to c
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> The Firebird guys have gotten around to releasing 1.0. If you read this
> front page spiel, you'll notice that they use MVCC, but with an overwriting
> storage manager.
Yup. I've had a couple of long chats with Ann Harrison at the recent
"
On Tue, 16 Apr 2002, Curt Sampson wrote:
> > Given the very low parsing and 'planning' overhead, the real cost would be
> > WAL (the bootstrapper could fail and render the database unusable) and the
> > subsequent updating of on-disk relations.
>
> MS SQL Server, when doing a BULK INSERT or BCP,
Rod Taylor wrote:
> [ copied to hackers ]
>
> > 1. I don't like the code that installs and removes ad-hoc
> dependencies
> > from relations to type Oid. On its own terms it's wrong (if it were
Looks good to me. I realize this is a huge chunk of code. The only
ultra-minor thing I saw was the u
On Sun, Apr 14, 2002 at 10:15:50PM -0400, Tom Lane wrote:
> Could this get cleaned up please?
Argh! Sorry, don't know how that typo made it in. I just fixed it.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---
90 matches
Mail list logo
