I've been examining the pg_dump source and output, and I've come to the
conclusion that I can modify it so that UNIQUE constraints appear as part of
the CREATE TABLE statement, rather than as a separate CREATE INDEX. I know
it is possible because phpPgAdmin does it!
This change should also be in
> I think it's certain that the original poster didn't realize Vadim is not
> a native English speaker, which is why I made my comment (to clue him in).
> Vadim didn't take my comment as criticism, as his follow-on post
> made clear
> (he got the joke). I don't know from your post if you thought
"xuyifeng" <[EMAIL PROTECTED]> writes:
> stock# create table a(i int2, j int);
> stock# create unique index idx_a on a(i, j);
> stock# explain select * from a where i=1 and j=0;
> psql:test.sql:4: NOTICE: QUERY PLAN:
> Seq Scan on a (cost=0.00..25.00 rows=1 width=6)
The constant "1" is implic
> I don't know from your post if you thought I was adding
> to the criticism or not, but I can say with certainty I wasn't.
No, I saw that you understood perfectly, I just wanted to add another
two cents...
> I'm not denigrating the current efforts, because PG documention's pretty
> good all th
I did VACUUM ANALYZE, there is no effect.
XuYifeng
- Original Message -
From: Don Baccus <[EMAIL PROTECTED]>
To: xuyifeng <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 22, 2000 10:51 AM
Subject: Re: [HACKERS] query plan optimizer bug
> At 10:46 AM 11/22/00 +0800,
At 12:29 AM 11/22/00 -0500, Tom Lane wrote:
>>> Is there any particular reason the spelling and punctuation in the code
>>> snippet below is so bad?
>
>> Vadim's Russian. This impacts his english but not his ability to implement
>> complex features like MVCC and WAL :)
>
>As someone who can't spe
> As someone who can't speak anything but English worth a damn (even
> though I was raised in Spanish-speaking countries, so you'd think
> I'd have acquired at least one clue), I have long since learned not
> to criticize the English of non-native speakers. Many of the
> participants in this proj
>> Is there any particular reason the spelling and punctuation in the code
>> snippet below is so bad?
> Vadim's Russian. This impacts his english but not his ability to implement
> complex features like MVCC and WAL :)
As someone who can't speak anything but English worth a damn (even
though I
At 10:46 AM 11/22/00 +0800, xuyifeng wrote:
>Hi,
>
>it's obviously there is a query plan optimizer bug, if int2 type used in
fields,
>the plan generator just use sequence scan, it's stupid
Have you checked this with real data after doing a VACUUM ANALYZE?
- Don Baccus, Portland OR <[EMAIL PROT
Hi,
it's obviously there is a query plan optimizer bug, if int2 type used in fields,
the plan generator just use sequence scan, it's stupid, i am using PG7.03,
this is my log file:
-
stock# drop table a;
DROP
stock# create table a(i int2, j int);
CREATE
stock# create unique index idx_a o
Just speaking Russian and English both (to any degree) is absolutely
amazing, put that on top of MVCC and WAL and we have Vadim, the smartest
person alive! *grin*
-Mitch
- Original Message -
From: "Mikheev, Vadim" <[EMAIL PROTECTED]>
To: "'Don Baccus'" <[EMAIL PROTECTED]>; "Christopher K
> >Is there any particular reason the spelling and punctuation
> in the code
> >snippet below is so bad?
>
> Vadim's Russian. This impacts his english but not his
> ability to implement complex features like MVCC and WAL :)
Yes, sorry guys. C lang is much easier -:))
Vadim
FWIW, I can freely reproduce this from a database dump and a short script which defines indexes and does a vacuum. They total about 600k, if anyone wants me to send them...
At 22:38 20/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> TRAP: Failed Assertion("!(((fil
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Should the parameter determine the directory or the full file name? I'd
> go for the former, but it's not a strong case.
> >>
> >> Directory was what I had in mind too, but I'm not sure what
At 09:14 AM 11/22/00 +0800, Christopher Kings-Lynne wrote:
>Is there any particular reason the spelling and punctuation in the code
>snippet below is so bad?
Vadim's Russian. This impacts his english but not his ability to implement
complex features like MVCC and WAL :)
- Don Baccus, Portland
Is there any particular reason the spelling and punctuation in the code
snippet below is so bad?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Eisentraut
> Sent: Wednesday, November 22, 2000 6:04 AM
> To: PostgreSQL Development
> Subj
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>> Modified Files:
>> README.pg_dumplo lo_export.c lo_import.c main.c pg_dumplo.h
>> utils.c
>>
>> Code review: minor cleanups, make the world safe for unsigned OIDs.
>> Improve documentation, too.
> Doesn't pg_dump handle
[EMAIL PROTECTED] writes:
> Date: Tuesday, November 21, 2000 @ 19:00:55
> Author: tgl
>
> Update of /home/projects/pgsql/cvsroot/pgsql/contrib/pg_dumplo
> from hub.org:/home/projects/pgsql/tmp/cvs-serv39905
>
> Modified Files:
> README.pg_dumplo lo_export.c lo_import.c main.c pg_du
At 02:01 PM 11/21/00 -0800, Mikheev, Vadim wrote:
>> This snippet in xlog.c makes we wonder...
>>
>> else if (ControlFile->state == DB_IN_RECOVERY)
>> {
>> elog(LOG, "Data Base System was interrupted
>> being in recovery at %s\n"
>> "\tThis propably m
> This snippet in xlog.c makes we wonder...
>
> else if (ControlFile->state == DB_IN_RECOVERY)
> {
> elog(LOG, "Data Base System was interrupted
> being in recovery at %s\n"
>"\tThis propably means that some data
> blocks are corrupted\n"
>
Jan Wieck writes:
> Stephan Szabo wrote:
> >
> >There's a message on -general about a possible
> > problem in the deferred RI constraints. He was doing a
> > sequence like:
> > begin
> > delete
> > insert
> > end
> > and having it fail even though the deleted key was back in
> > place at t
Larry Rosenman writes:
> Want me to do a new patch, or will you fix mine?
I'll fix all these things. I'm also somewhat annoyed that these messages
show up during initdb now. Anyone know why exactly? I couldn't trace it
down.
>
> LER
>
> * Peter Eisentraut <[EMAIL PROTECTED]> [001121 11:5
Stephan Szabo wrote:
>
>There's a message on -general about a possible
> problem in the deferred RI constraints. He was doing a
> sequence like:
> begin
> delete
> insert
> end
> and having it fail even though the deleted key was back in
> place at the end.
Isn't that (delete and r
Want me to do a new patch, or will you fix mine?
LER
* Peter Eisentraut <[EMAIL PROTECTED]> [001121 11:51]:
> Larry Rosenman writes:
>
> > --- 1426,1432
> > ControlFile->catalog_version_no, CATALOG_VERSION_NO);
> >
> > if (ControlFile->state == DB_SHUTDOWNED)
>
At 10:58 AM 11/21/00 -0500, Tom Lane wrote:
>> The MySQL folk have always cherry-picked their benchmarks, long lied
>> about features in PG, do their benchmarking using default values
>> for PG's shared buffer etc WITHOUT TELLING PEOPLE while at the same
>> time installing MySQL with larger-than-
Larry Rosenman writes:
> --- 1426,1432
>ControlFile->catalog_version_no, CATALOG_VERSION_NO);
>
> if (ControlFile->state == DB_SHUTDOWNED)
> ! elog(LOG, "Data Base System was shutdown at %s",
shut down (two words)
>str_ti
I've subscribed and un-subscribed to the HACKERS-DIGEST list several
times now. Each time I seem to be getting EVERY message sent to the list
rather than a DIGEST.
Can someone tell me if it is still possible to get a DIGEST of the list?
Is the list administrator aware of the problem?
Thanks.
-To
> > >SET SESSION CHARACTERISTICS AS parameter value
> > > is really a more SQL'ish form of the current
> > >SET parameter =/TO value
> > > Perhaps they should be made equivalent, in order to avoid too many subtly
> > > different subversions of the 'SET' command.
> > Hmm. What do you mean b
Thomas Lockhart writes:
> >SET SESSION CHARACTERISTICS AS parameter value
> > is really a more SQL'ish form of the current
> >SET parameter =/TO value
> > Perhaps they should be made equivalent, in order to avoid too many subtly
> > different subversions of the 'SET' command.
>
> Hmm. Wh
Don Baccus <[EMAIL PROTECTED]> writes:
> Great Bridge didn't do the benchmarking, they hired a third party to
> do so. And that third party didn't, AFAIK, cherry-pick tests in order
> to "prove" PG's superiority.
In fairness, the third party was Xperts Inc, who have long done a lot
of programmin
Pete Forman <[EMAIL PROTECTED]> writes:
> I thought that Great Bridge's August benchmarks were rather skewed.
> They only used one particular test from the AS3AP suite.
AFAIK there was nothing particularly sinister about that --- they
didn't have time to run a large number of different tests, so
At 12:18 AM 11/21/00 -0500, Tom Lane wrote:
>Don Baccus <[EMAIL PROTECTED]> writes:
>> If this problem is attacked, should one stop at constraints or make certain
>> that other elements like views are dumped properly, too? (or were views
>> fixed for 7.1, I admit to a certain amount of "ignoring
At 10:19 AM 11/21/00 +, Pete Forman wrote:
>Don Baccus writes:
> > I also hope that the PG crew, and Great Bridge, never stoop so low
> > as to ship benchmarks wired to "prove" PG's superiority.
>
>I thought that Great Bridge's August benchmarks were rather skewed.
>They only used one particul
> I've wondered and am still wondering what a lot of these benchmark tests
> are out to prove.
In this case, the "benchmark test" was not out to prove anything. It was
an good-faith result of a porting effort with a suprising (to the
tester) result.
> I'm not sure that any PostgreSQL advocat
Fix some english issues...
I also note some "interesting" (from an English perspective) #define
names that mayhaps need to be looked at.
Index: xlog.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/access/transam/xl
Don Baccus writes:
> I also hope that the PG crew, and Great Bridge, never stoop so low
> as to ship benchmarks wired to "prove" PG's superiority.
I thought that Great Bridge's August benchmarks were rather skewed.
They only used one particular test from the AS3AP suite. That was the
basis for
> > Nope. Still fails...
> >
> > You should've said that the OIDs are now just off-by-one from where they
> > were before, instead of off by several thousand. That I'm willing to
> > accept as an implementation change ;-) I've updated the expected file.
^^^
> > Nope. Still fails...
> >
> > You should've said that the OIDs are now just off-by-one from where they
> > were before, instead of off by several thousand. That I'm willing to
> > accept as an implementation change ;-) I've updated the expected file.
^^^
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/adt
> > Modified Files:
> > ri_triggers.c
> > keep relations open until they are no longer needed.
>
> Something that's been bothering me for a good while about ri_triggers
> is tha
At 15:10 21/11/00 +0800, Christopher Kings-Lynne wrote:
>> CREATE TABLE example
>> ( example_id serial
>>
>> -- Must be a ZIP or Postal Code
>> , regionvarchar(6)
>>
>> -- Descriptive text
>> , description varchar(60)
>> );
>
>Actually - this is something I _could_ do.
>
>As the pg_
40 matches
Mail list logo
