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!
---
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 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,
"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
"
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
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
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
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
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
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
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
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
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
> > 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
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
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.
> >
>
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
[ 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 /
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
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
> 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
> 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
...
> 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
> 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
...
> 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 different locales, a
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
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
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
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
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
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
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
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
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://
> 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
> 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
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
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
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
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
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
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
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
"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
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
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
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 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
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
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>
> 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
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
"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
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 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
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
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
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
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
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
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
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
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
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
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%
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
"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
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
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
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
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
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 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
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
> 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
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.
> 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
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!
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
>"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 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
> 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 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
>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 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
> 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
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:
> >
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'
90 matches
Mail list logo
