> What is the difference
> between a trigger, a rule and an instead rule from a business process
> oriented point of view? I think there is none at all. They are just
> different techniques to do one and the same, implement
> business logic in the database system.
The difference is how other db'
> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
>
> We don't have a whole lot of freedom in this; this area is
> covered by th
On Tue, 10 Sep 2002, Bruce Momjian wrote:
> Interesting that random time is increasing, while the others were
> stable. I think this may have to do with other system activity at the
> time of the test.
Actually, the random versus sequential time may also be different
depending on how many proce
I got somewhat different:
$ ./randcost /usr/local/pgsql/data
Collecting sizing information ...
Running random access timing test ...
Running sequential access timing test ...
Running null loop timing test ...
random test: 13
sequential test: 15
null timing test: 11
random_page_cost = 0.
OK, I have a better version at:
ftp://candle.pha.pa.us/pub/postgresql/randcost
I have added a null loop which does a dd on a single file without
reading any data, and by netting that loop out of the total computation
and increasing the number of tests, I have gotten the following results
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Has there been any talk of doing incremental -snapshots of the code
> base?
I don't really see the point. Snapshots of development code are
available from CVS anyway -- and if you're going to be running a
pre-alpha version of a relational database, I
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Agreed, however some of the loop-unrolling might prove to have some
> optimization, but we'll see. I'd like to think that there's some
> actual value in -O6 beyond the geek appeal of being able to say it's
> been compiled with all the optimizations po
On Mon, 9 Sep 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > On Mon, 9 Sep 2002, Tom Lane wrote:
> >> ... We are trying to measure the behavior when kernel
> >> caching is not helpful; if the database fits in RAM then you are just
> >> naturally going to get random_page_cos
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Mon, 9 Sep 2002, Tom Lane wrote:
>> ... We are trying to measure the behavior when kernel
>> caching is not helpful; if the database fits in RAM then you are just
>> naturally going to get random_page_cost close to 1, because the kernel
>> will avoid
Curt Sampson <[EMAIL PROTECTED]> writes:
> Probably the driver should be changed for 7.3 just to use the server's
> SET AUTOCOMMIT functionality
That should happen eventually, IMHO, but I am not going to tell the JDBC
developers that they must make it happen for 7.3. They've already got a
pi
Hello Christopher,
Monday, September 9, 2002, 11:36:44 PM, you wrote:
CKL> Sorry guys - it's killing me! It's 'affected' in the subject line - not
CKL> 'effected'!!! Sigh :)
lol... my bad, English is not my primary language and these things
just seem to happen sometimes... I apologize.
--
Hello Bruce,
Monday, September 9, 2002, 11:13:20 PM, you wrote:
BM> Steve Howe wrote:
>> Because the affected commands are supposed to give you back
>> information on what your INSERT/UPDATE/DELETE commands, not what is
>> making behind the scenes.
>>
>> And it seems that other people in the th
> > > > My feeling is that gcc -O2 is quite well tested with the PG
> > > > code. I don't have any equivalent confidence in -O6. Give it
> > > > a shot for beta-testing, for sure, but I'm iffy about calling
> > > > that a production-grade database release...
> > >
> > > And of course the big qu
Sean Chittenden wrote:
> > > > The size difference between -O and -O3 is only 200K or so... does
> > > > anyone think that it'd be safe to head to -O6 on a wide scale?
> > >
> > > Dunno. I'm not aware of any bits of the code that are unportable enough
> > > to break with max optimization of any
> > > The size difference between -O and -O3 is only 200K or so... does
> > > anyone think that it'd be safe to head to -O6 on a wide scale?
> >
> > Dunno. I'm not aware of any bits of the code that are unportable enough
> > to break with max optimization of any correct compiler. But you might
On Mon, 9 Sep 2002, Tom Lane wrote:
> If autocommit=off really seriously breaks JDBC then I don't think a
> simple SET command at the start of a session is going to do that much
> to improve robustness. What if the user issues another SET to turn it
> on?
You mean, to turn it off again? The dri
Curt Sampson wrote:
> On Mon, 9 Sep 2002, Sean Chittenden wrote:
>
> > I'm thinking about changing this from a beta port to a -devel port
> > that I'll periodically update with snapshots. I'll turn on -O6 for
> > the -devel port and -O2 for production for now. If I don't hear of
> > any random
Sean Chittenden wrote:
> Hrm, I should go check the archives, but I thought what was used was
> one step below -C[fF] and was used because of size concerns for
> embedded databases. My memory for what happens on mailing lists seems
> to be fading though so I'll look it up.
I see in parser/Makefi
On Mon, 9 Sep 2002, Sean Chittenden wrote:
> I'm thinking about changing this from a beta port to a -devel port
> that I'll periodically update with snapshots. I'll turn on -O6 for
> the -devel port and -O2 for production for now. If I don't hear of
> any random bogons in the code I'll see if I
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> > The size difference between -O and -O3 is only 200K or so... does
> > anyone think that it'd be safe to head to -O6 on a wide scale?
>
> Dunno. I'm not aware of any bits of the code that are unportable enough
> to break with max o
> > The size difference between -O and -O3 is only 200K or so... does
> > anyone think that it'd be safe to head to -O6 on a wide scale?
>
> Dunno. I'm not aware of any bits of the code that are unportable
> enough to break with max optimization of any correct compiler. But
> you might find suc
On Mon, 9 Sep 2002, Tom Lane wrote:
> Finally, I wouldn't believe the results for a moment if they were taken
> against databases that are not several times the size of physical RAM
> on the test machine, with a total I/O volume also much more than
> physical RAM. We are trying to measure the be
On Mon, 9 Sep 2002, Tom Lane wrote:
> snpe <[EMAIL PROTECTED]> writes:
>
> > snpe> select * from org_ba;
> > ERROR: relation org_ba does not exists
> > snpe> select * from org_ban;
> > ERROR: current transactions is aborted, queries ignored until end of
> > transaction block
>
> Um, what's wrong
Sean Chittenden <[EMAIL PROTECTED]> writes:
> The size difference between -O and -O3 is only 200K or so... does
> anyone think that it'd be safe to head to -O6 on a wide scale?
Dunno. I'm not aware of any bits of the code that are unportable enough
to break with max optimization of any correct c
Sorry guys - it's killing me! It's 'affected' in the subject line - not
'effected'!!! Sigh :)
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
> Sent: Tuesday, 10 September 2002 10:24 AM
> To: Peter Eisentraut
> Cc: Steve Howe;
snpe <[EMAIL PROTECTED]> writes:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from org_ban;
> E
Peter Eisentraut wrote:
> Steve Howe writes:
>
> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
>
> We don't have a whole lot of
On Mon, 2002-09-09 at 22:11, Bruce Momjian wrote:
> Jan Wieck wrote:
> > We should surely keep this on a much more technical level and avoid any
> > personal offendings. To do so, please explain to me why you think that
> > triggers and constraints are out of focus here? What is the difference
> >
On Mon, 9 Sep 2002, Bruce Momjian wrote:
> Jan Wieck wrote:
> > We should surely keep this on a much more technical level and avoid any
> > personal offendings. To do so, please explain to me why you think that
> > triggers and constraints are out of focus here? What is the difference
> > between
Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > I didn't download the beta but compared the CVS checkouts and it appears
> > the ecpg directory is still the one from 7.2 not the one tagged
> > big_bison. Will this one be moved into the mainstream source?
>
> Well, I think we can'
On Tue, 10 Sep 2002, snpe wrote:
> On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> > On Tue, 10 Sep 2002, snpe wrote:
> > > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > > I'm use 'autocommit=false' and have problem
Steve Howe wrote:
> Because the affected commands are supposed to give you back
> information on what your INSERT/UPDATE/DELETE commands, not what is
> making behind the scenes.
>
> And it seems that other people in the thread agree with me, please
> read thread.
>
> Since you are probably very
Jan Wieck wrote:
> We should surely keep this on a much more technical level and avoid any
> personal offendings. To do so, please explain to me why you think that
> triggers and constraints are out of focus here? What is the difference
> between a trigger, a rule and an instead rule from a busine
Actually, this problem is part of a whole scope of problems that were in
the Berkeley code, because rules, and inheritance, just have a certain
contorting effect on SQL queries where it is difficult to get them
working properly.
If these features didn't come from Berkeley, I doubt we would have e
On Tuesday 10 September 2002 03:05 am, Stephan Szabo wrote:
> On Tue, 10 Sep 2002, snpe wrote:
> > On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > > I'm use 'autocommit=false' and have problem with psql
> > > > When any commnad is lost,
Nick Fankhauser wrote:
> Hi again-
>
> I bounced these numbers off of Ray Ontko here at our shop, and he pointed
> out that random page cost is measured in multiples of a sequential page
> fetch. It seems almost impossible that a random fetch would be less
> expensive than a sequential fetch, yet
On Tue, 10 Sep 2002, snpe wrote:
> On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> > On Mon, 2002-09-09 at 17:04, snpe wrote:
> > > I'm use 'autocommit=false' and have problem with psql
> > > When any commnad is lost, then next commnad get error for transactions
> > > (simple select co
On Monday 09 September 2002 11:03 pm, Rod Taylor wrote:
> On Mon, 2002-09-09 at 17:04, snpe wrote:
> > I'm use 'autocommit=false' and have problem with psql
> > When any commnad is lost, then next commnad get error for transactions
> > (simple select command).BTW
> >
> > snpe> select * from org_ba
Dear Tom,
>> <[EMAIL PROTECTED]> writes:
>> But when I try to import it inside 7.3b1 I get this :
>> (seems that the copy command is not fully compatible with the 7.2.2
>> pg_dumpall ?)
>>
>> Many thinks like this : (I have only copied some parts ...)
>> Size of the dump about 1.5 Gb ...
>>
>> Qu
At 03:54 PM 9/09/2002 -0700, Laurette Cisneros wrote:
>Ok, I made the changes in the compressed pg_dump file.
That's probably a very bad idea.
It's a little more long-winded, but try:
pg_restore -l dumpfile > dump1.lis
copy dump1.lis to dump2.lis
delete everything from dump1.lis at and after
Ok, I made the changes in the compressed pg_dump file. Now pg_restore crashes:
pg_restore: [archiver] out of memory
*sigh*
L.
On 9 Sep 2002, Oliver Elphick wrote:
> On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote:
> >
> > I am trying move my development database to 7.3b1.
> >
> > Howev
Hello Jan,
Monday, September 9, 2002, 4:56:04 PM, you wrote:
JW> Steve Howe wrote:
>>
>> Hello Jan,
>>
>> Monday, September 9, 2002, 11:15:47 AM, you wrote:
>>
>> JW> So please, "proper behavior" is not allways what your favorite tool
>> JW> expects. And just because you cannot "fix" your too
Ok, am I missing somethig here?
In 7.3, the -Fp option has been removed which leaves the -Fc (which we use
in our 7.2 dumps) or -Ft.
How does one edit a compressed or tar file?
Also, is this problem going to be fixed in a later beta or regular release
of 7.3? This could pose a problem to rest
In an attempt to beef up the PostgreSQL port for FreeBSD, I've added
an option for adding additional optimization, similar to what MySQL
does by compiling the server with -O6. I'm only compiling at -O3 with
the flag at the moment, however I wanted to ping the idea around to
make sure this isn't s
I've put together some packages for the 7.3beta1 release. The can be
found here along with a tenative FreeBSD port:
http://66.250.180.19/postgresql-7.3beta1/
The differences in the files are that the postgresql-7.3b1-O3.tbz has
been compiled with -O3 where as the postgresql-7.3b1.tbz hasn't.
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> I bounced these numbers off of Ray Ontko here at our shop, and he pointed
> out that random page cost is measured in multiples of a sequential page
> fetch. It seems almost impossible that a random fetch would be less
> expensive than a sequential fe
On Mon, 2002-09-09 at 17:04, snpe wrote:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
>
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from o
Thanks!
On 9 Sep 2002, Oliver Elphick wrote:
> On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote:
> >
> > I am trying move my development database to 7.3b1.
> >
> > However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get
> > the following error:
> >
> > pg_restore -U nb
On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote:
>
> I am trying move my development database to 7.3b1.
>
> However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get
> the following error:
>
> pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp
>
> pg_rest
On Mon, 9 Sep 2002, Laurette Cisneros wrote:
>
> I am trying move my development database to 7.3b1.
>
> However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get
> the following error:
>
> pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp
>
> pg_restore: [ar
On Monday 09 September 2002 08:53 pm, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Barry Lind wrote:
> >> How should client interfaces handle this new autocommit feature? Is it
> >> best to just issue a set at the beginning of the connection to ensure
> >> that it is always on?
Hello Peter,
Monday, September 9, 2002, 3:41:41 PM, you wrote:
PE> Steve Howe writes:
>> Here are the proposals for solutioning the "Return proper effected
>> tuple count from complex commands [return]" issue as seen on TODO.
>>
>> Any comments ?... This is obviously open to voting and discussi
I am trying move my development database to 7.3b1.
However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get
the following error:
pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp
pg_restore: [archiver (db)] could not execute query: ERROR: function
plpgsql_c
Steve Howe wrote:
>
> Hello Jan,
>
> Monday, September 9, 2002, 11:15:47 AM, you wrote:
>
> JW> So please, "proper behavior" is not allways what your favorite tool
> JW> expects. And just because you cannot "fix" your tool doesn't make that
> JW> behavior any more "proper".
> Do you have any wo
> -Original Message-
> From: Ross J. Reedstrom [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 09, 2002 12:26 PM
> To: Dann Corbit
> Cc: Rod Taylor; Steve Howe; PostgreSQL-development
> Subject: Re: [HACKERS] Rule updates and PQcmdstatus() issue
>
>
> On Mon, Sep 09, 2002 at 11:30:
> > If we didn't do that, then Postgresql never would have been
> > released in the first place, nor any date between then and now.
> I believe that the surprise is at the focus, when it comes to a release.
> With commercial products (anyway) if you have any sort of show-stopper
> bug (crashing,
Daryl,
The problem is an incompatiblity between a new server autocommit feature
and the existing jdbc autocommit feature. The problem manifests itself
when you turn autocommit off on the server (which is new functionality
in 7.3). If you leave autocommit turned on on the server (which is the
On Mon, Sep 09, 2002 at 11:30:52AM -0700, Dann Corbit wrote:
> >
> > I suspect it'll be several more major releases before we
> > begin to consider it approaching completely functional.
>
> I believe that the surprise is at the focus, when it comes to a release.
> With commercial products (anyw
On Mon, Sep 09, 2002 at 11:30:52AM -0700, Dann Corbit wrote:
>
> All kidding aside, I would like to see increased emphasis on stability
> and correctness. But I will admit that it is a lot less fun than adding
> new features.
But in fairness, I think you'd be hard pressed to find a set of
devel
=?iso-8859-1?B?SGVydukgUGllZHZhY2hl?= <[EMAIL PROTECTED]> writes:
> But when I try to import it inside 7.3b1 I get this :
> (seems that the copy command is not fully compatible with the 7.2.2
> pg_dumpall ?)
> Many thinks like this : (I have only copied some parts ...)
> Size of the dump about 1
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Barry Lind wrote:
>> How should client interfaces handle this new autocommit feature? Is it
>> best to just issue a set at the beginning of the connection to ensure
>> that it is always on?
> Yes, I thought that was the best fix for apps that can't dea
Steve Howe writes:
> Here are the proposals for solutioning the "Return proper effected
> tuple count from complex commands [return]" issue as seen on TODO.
>
> Any comments ?... This is obviously open to voting and discussion.
We don't have a whole lot of freedom in this; this area is covered b
Thomas Lockhart writes:
> > SIMILAR TO doesn't implement the SQL standard, it's only a wrapper around
> > the POSIX regexp matching, which is wrong. I thought someone wanted to
> > fix that, but if it's not happening it should be removed.
>
> Please be specific on what you would consider correct
Hervé Piedvache writes:
> Any idea ?
No.
We need the complete details (including the input files), not vague
observations.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.
Hi again-
I bounced these numbers off of Ray Ontko here at our shop, and he pointed
out that random page cost is measured in multiples of a sequential page
fetch. It seems almost impossible that a random fetch would be less
expensive than a sequential fetch, yet we all seem to be getting results
> -Original Message-
> From: Rod Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 09, 2002 10:55 AM
> To: Steve Howe
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Rule updates and PQcmdstatus() issue
>
>
> > existed, had a brief discussion on the subject, and
> could
On Mon, 9 Sep 2002, Steve Howe wrote:
> JW> Steve Howe wrote:
> >>
> >> Hello all,
> >>
> >> PostgreSQL *still* has a bug where PQcmdStatus() won't return the
> >> number of rows updated. But that is essential for applications, since
> >> without it of course we don't know if the updates/delete/
I'm getting an infinite wait on that file, could someone post it to the
list please?
On Mon, 9 Sep 2002, Bruce Momjian wrote:
>
> OK, turns out that the loop for sequential scan ran fewer times and was
> skewing the numbers. I have a new version at:
>
> ftp://candle.pha.pa.us/pub/pos
> existed, had a brief discussion on the subject, and couldn't reach an
> agreement. That's ok for me, I understand... but releasing versions
> known to be broken is something I can't understand.
-9' the postmaster
If we didn't do that, then Postgresql never would have been released in
the first
Hello Jan,
Monday, September 9, 2002, 11:15:47 AM, you wrote:
JW> Steve Howe wrote:
>>
>> Hello all,
>>
>> PostgreSQL *still* has a bug where PQcmdStatus() won't return the
>> number of rows updated. But that is essential for applications, since
>> without it of course we don't know if the upd
Vince Vielhaber wrote:
>
> Still don't know where Peter's going to be so his pin may end up
> in Dresden. I've had zero success in getting that tcl tool to work
> which is the current holdup but I do have all the updates I know of
> that are needed.
You mean that Tcl/Tk application that manages
Hello Jan,
Monday, September 9, 2002, 11:26:20 AM, you wrote:
JW> Seems you at least realized how serious it is. Even if you cannot code
JW> the "proper" solution, could you please make a complete table of all
JW> possible situations and the expected returns? With complete I mean
JW> including a
Hello Jan,
Monday, September 9, 2002, 11:26:20 AM, you wrote:
JW> Steve Howe wrote:
>>
>> Hello Bruce,
>>
>> Friday, September 6, 2002, 9:52:18 PM, you wrote:
>>
>> BM> I am not any happier about it than you are. Your report is good because
>> BM> it is the first case where returning the wro
On Mon, 9 Sep 2002, Jan Wieck wrote:
> Christopher Kings-Lynne wrote:
> >
> > Anyone else think we should add some more pins to the developer map? At the
> > moment, it looks like we have very few developers!
>
> We might as well refresh that thing a bit. I haven't been to Hamburg
> since April
On Mon, 2002-09-09 at 01:16, Hans-Jürgen Schönig wrote:
> Christopher Kings-Lynne wrote:
>
> >Assuming it's giving out correct information, there seems to be a lot of
> >evidence for dropping the default random_page_cost to 1...
> >
> >Chris
> >
> >
> Some time ago Joe Conway suggest a tool bas
Tom Lane wrote:
>>Joe Conway <[EMAIL PROTECTED]> writes:
>>
>>>I found the following while poking around. RangeVarGetRelid takes a
>>>second parameter that is intended to allow it to not fail, returning
>>>InvalidOid instead. However it calls LookupExplicitNamespace, which does
>>>not honor any
Bruce-
With the change in the script that I mentioned to you off-list (which I
believe just pointed it at our "real world" data), I got the following
results with 6 successive runs on each of our two development platforms:
(We're running PGSQL 7.2.1 on Debian Linux 2.4)
System 1:
1.2 GHz Athlon
I said:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> I found the following while poking around. RangeVarGetRelid takes a
>> second parameter that is intended to allow it to not fail, returning
>> InvalidOid instead. However it calls LookupExplicitNamespace, which does
>> not honor any such reque
Karel Zak <[EMAIL PROTECTED]> writes:
> 1/ ExecuteQuery() (line 110). Why is needful use copyObject()? The
> PostgreSQL executor modify query planns?
Yes, and yes. Unfortunately.
> 2/ Lines 236 -- 245. Why do you "check for pre-existing entry of
> same name" if you create hash table?
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Assuming it's giving out correct information, there seems to be a lot of
> evidence for dropping the default random_page_cost to 1...
The fact that a lot of people are reporting numbers below 1 is
sufficient evidence that the script is broke
> could you please make a complete table of all
> possible situations and the expected returns? With complete I mean
> including all combinations of rules, triggers, deferred constraints and
> the like. Or do you at least see now where in the discussion we got
> stuck?
Imho only view rules (== in
Christopher Kings-Lynne wrote:
>
> Anyone else think we should add some more pins to the developer map? At the
> moment, it looks like we have very few developers!
We might as well refresh that thing a bit. I haven't been to Hamburg
since April 2001! Vince already has my ... er ... rather old
> I don't think we should add tuple counts from different commands, i.e.
> adding UPDATE and DELETE counts just yields a totally meaningless
> number.
Agreed.
> I don't think there is any need/desire to add additional API routines to
> handle multiple return values.
Yup.
> Can I get some vo
Steve Howe wrote:
>
> Hello Bruce,
>
> Friday, September 6, 2002, 10:58:13 PM, you wrote:
>
> BM> Well, there was a big discussion, and I did bring up the issue in early
> BM> August to see if I could get a resolution to it and was told no
> BM> conclusion could be made.
>
> BM> I suggest you
Steve Howe wrote:
>
> Hello Bruce,
>
> Friday, September 6, 2002, 9:52:18 PM, you wrote:
>
> BM> I am not any happier about it than you are. Your report is good because
> BM> it is the first case where returning the wrong value actually breaks
> BM> software. You may be able to justify adding
> Should we check for stop words before stemming or after ?
Current implementation supports both variants. Look dictionary interface
definition in morph.c:
typedef struct
{
charlocalename[NAMEDATALEN];
/* init dictionary */
void *(*init) (void);
On Fri, 2002-09-06 at 06:54, Tim Knowles wrote:
> Hi,
>
> Been playing with the 7.3beta1 version and I've noticed a small
> problem with dependency checking when dropping a column. If you have
> a view which uses JOIN's to join tables then dropping a column will
This has to do with the way the
Steve Howe wrote:
>
> Hello all,
>
> PostgreSQL *still* has a bug where PQcmdStatus() won't return the
> number of rows updated. But that is essential for applications, since
> without it of course we don't know if the updates/delete/insert
> commands succeded. Even worst, on interfaces like Del
>From the Department of Redundancy Department:
Attached is a perl script called 'pguniqchk'. It checks the uniqueness
of unique constraints on tables in a PostgreSQL database using the
PG_TABLES and PG_INDEXES system "tables".
Why would this be useful?
If you're planning to dump and restore th
Hi,
Been playing with the 7.3beta1 version and I've noticed a small
problem with dependency checking when dropping a column. If you have
a view which uses JOIN's to join tables then dropping a column will
fail on a dependency check, even though the column being dropped is
not used at all in the
On Mon, Sep 09, 2002 at 09:38:39AM -0400, Tom Lane wrote:
> Well, I think we can't do that until postgresql.org has a version of
> bison installed that will compile it. And I'm really hesitant to see us
> depending on a beta version of bison. Any word on a new bison official
> release?
No news
Michael Meskes <[EMAIL PROTECTED]> writes:
> I didn't download the beta but compared the CVS checkouts and it appears
> the ecpg directory is still the one from 7.2 not the one tagged
> big_bison. Will this one be moved into the mainstream source?
Well, I think we can't do that until postgresql.o
Joe Conway <[EMAIL PROTECTED]> writes:
> I found the following while poking around. RangeVarGetRelid takes a
> second parameter that is intended to allow it to not fail, returning
> InvalidOid instead. However it calls LookupExplicitNamespace, which does
> not honor any such request, and happil
On Mon, 2002-09-09 at 02:13, Bruce Momjian wrote:
>
> OK, turns out that the loop for sequential scan ran fewer times and was
> skewing the numbers. I have a new version at:
>
> ftp://candle.pha.pa.us/pub/postgresql/randcost
>
> I get _much_ lower numbers now for random_page_cost.
The c
On Mon, 2002-09-09 at 07:13, Bruce Momjian wrote:
>
> OK, turns out that the loop for sequential scan ran fewer times and was
> skewing the numbers. I have a new version at:
>
> ftp://candle.pha.pa.us/pub/postgresql/randcost
>
> I get _much_ lower numbers now for random_page_cost.
>
> -
> What do other people get for this value?
>
> Keep in mind if we increase this value, we will get a more sequential
> scans vs. index scans.
With the new script I get 0.929825 on 2 IBM DTLA 5400RPM (80GB) with a 3Ware
6400 Controller (RAID-1)
Best regards,
Mario Weilguni
--
Bruce
I am trying to populate a 7.3 database from a 7.2 dump. I used 7.3's
pg_dumpall, but this did not handle all the issues:
1. The language dumping needs to be improved:
CREATE FUNCTION plperl_call_handler () RETURNS opaque
^^
AS '
> intarray and ltree both seem to be mapping their own declarations onto
> arrays using largely-similar code. But while intarray fails its
> regression test, I find ltree still passes. So I'm confused about what
> that code is really doing and don't want to touch it.
Please, apply attached pa
On Mon, 9 Sep 2002, Bruce Momjian wrote:
> What do other people get for this value?
With your new script, with a 1.5 GHz Athlon, 512 MB RAM, and a nice fast
IBM 7200 RPM IDE disk, I get random_page_cost = 0.93.
> One flaw in this test is that it randomly reads blocks from different
> files
Christopher Kings-Lynne wrote:
>Assuming it's giving out correct information, there seems to be a lot of
>evidence for dropping the default random_page_cost to 1...
>
>Chris
>
>
Some time ago Joe Conway suggest a tool based on a genetic algorithm
which tries to find the best parameter settings
1 - 100 of 105 matches
Mail list logo
