Hi there lovely,
I was asearching the net few days ago. I am new to this thing.
and saw your profible. I decided to email you cause I found
you attractive. I maight come down to youra city in fewb weeks.
Let me know if we can meet each other in person.
I am attractive girl. I am surea you won't
On Sun, Jun 18, 2006 at 05:26:16PM -0400, Tom Lane wrote:
I wrote:
PFC [EMAIL PROTECTED] writes:
So, the proposal :
On executing a command, Backend stores the command string, then
overwrites the counter with (counter + 1) and with the timestamp of
command start.
Periodically, like
On Sun, Jun 18, 2006 at 11:07:41PM -0400, Tom Lane wrote:
Bort, Paul [EMAIL PROTECTED] writes:
Anyone know a variant of this that really works?
Here's a theory: If the counter is bumped to an odd number before
modification, and an even number after it's done, then the reader will
know
Sorry folks, my fault ... hit the 'accept' button too fast :(
On Sat, 17 Jun 2006, Wilbur wrote:
Hi there lovely,
I was asearching the net few days ago. I am new to this thing.
and saw your profible. I decided to email you cause I found
you attractive. I maight come down to youra city in fewb
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 21 June 2006 20:43
To: Dave Page
Cc: Andrew Dunstan; Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CVS HEAD busted on Windows?
Dave Page dpage@vale-housing.co.uk writes:
Yeah - I've
Tom Lane wrote:
I'm trying to determine why thrush has been failing on PG CVS HEAD for
the past few days. Could you try running the attached program on that
machine, and see what it prints? I suspect it will dump core :-(
Note: you might need to use -D_GNU_SOURCE to get it to compile at
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled into
her beard:
We all know that PostgreSQL suffers performance problems when rows are
updated frequently prior to a vacuum. The most serious example can be
seen
by using PostgreSQL as a session handler for a busy we site. You may
Each time the record is updated, a new version is created, thus
lengthening the correct version search each time row is accessed,
until, of course, the next vacuum comes along and corrects the
index
to point to the latest version of the record.
Is that a fair explanation?
No,
I'm developing the summer of code project to create a xlog viewer.The tool we want to create is a DBA tool used for inspect the xlog files, looking for some operations, statistcs of database usage and status of transactions.
Some use cases:* Some user made a mistake and commited it to the
After a long battle with technology, [EMAIL PROTECTED] (Mark Woodward), an
earthling, wrote:
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled into
her beard:
We all know that PostgreSQL suffers performance problems when rows are
updated frequently prior to a vacuum. The most
Dave Page wrote:
As a sidenote on the postgres/postmaster merge subject though - Magnus
I were wondering if Peter's change means we no longer need to ship
postmaster.exe and postgres.exe with pgInstaller. Presumably we can just
use postgres.exe for everything now?
Won't we still need
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 22 June 2006 14:06
To: Dave Page
Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CVS HEAD busted on Windows?
Dave Page wrote:
As a sidenote on the
Arjen van der Meijden
wrote:
Here is a graph of our performance measured on PostgreSQL:
http://achelois.tweakers.net/~acm/pgsql-t2000/T2000-schaling-postgresql.png
...
The "perfect" line is based on the "Max" value for 1 core and then just
multiplied by the amount of cores to have
Dave Page wrote:
Won't we still need to know if we are called as postmaster or
postgres?
Unless the 'postmaster' instance starts all it's sub processes with an
additional option to tell them they're children (I haven't looked at the
code yet so I dunno if this is how it's done).
For
Dave Page wrote:
Won't we still need to know if we are called as postmaster or
postgres?
Unless the 'postmaster' instance starts all it's sub processes with an
additional option to tell them they're children (I haven't looked at the
code yet so I dunno if this is how it's done).
For
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 22 June 2006 14:26
To: Dave Page
Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] postmaster.exe vs postgres.exe
Windows children could be handled, I think, but here is
After a long battle with technology, [EMAIL PROTECTED] (Mark
Woodward), an earthling, wrote:
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled into
her beard:
[snip]
1. The index points to all the versions, until they get vacuumed out.
It can't point to all versions, it points
Gaetano Mendola [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm trying to determine why thrush has been failing on PG CVS HEAD for
the past few days. Could you try running the attached program on that
machine, and see what it prints? I suspect it will dump core :-(
$ gcc -D_GNU_SOURCE tom.c
Dave Page dpage@vale-housing.co.uk writes:
though - Magnus
I were wondering if Peter's change means we no longer need to ship
postmaster.exe and postgres.exe with pgInstaller. Presumably
we can just use postgres.exe for everything now?
Won't we still need to know if we are called as
Tom Lane wrote:
Won't we still need to know if we are called as postmaster or
postgres?
No. The entire point of the recent changes is that the behavior no
longer depends on the name of the executable, only on the switches.
Oh. My mistake. That sounds good.
cheers
andrew
Mark Woodward wrote:
Hmm, OK, then the problem is more serious than I suspected.
This means that every index on a row has to be updated on every
transaction that modifies that row. Is that correct?
Add an index entry, yes.
I am attaching some code that shows the problem with regard to
On 6/22/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Hmm, OK, then the problem is more serious than I suspected.
This means that every index on a row has to be updated on every
transaction that modifies that row. Is that correct?
Add an index entry, yes.
Again, this is a case for
[...]
There has to be a more linear way of handling this scenario.
So vacuum the table often.
Good advice, except if the table is huge :-)
Here we have for example some tables which are frequently updated but
contain 100 million rows. Vacuuming that takes hours. And the dead row
Qingqing Zhou [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote
postgres --single works for me. Maybe you need a make
distclean/rebuild?
Sorry, because I forget to say that you need to turn stats_command_string
on.
Ah. OK, fixed.
regards, tom lane
On 22-6-2006 15:03, David Roussel wrote:
Sureky the 'perfect' line ought to be linear? If the performance was
perfectly linear, then the 'pages generated' ought to be G times the
number (virtual) processors, where G is the gradient of the graph. In
such a case the graph will go through the
As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
I find __FILE__ and __LINE__ very helpful
Am Donnerstag, 22. Juni 2006 16:09 schrieb Csaba Nagy:
[...]
There has to be a more linear way of handling this scenario.
So vacuum the table often.
Good advice, except if the table is huge :-)
Here we have for example some tables which are frequently updated but
contain 100 million
[ redirecting to -hackers, as I see no need for this to be a core issue ]
Charles Comiskey [EMAIL PROTECTED] writes:
Hello,
I've recently looked through the PostgreSQL code and a couple of questions
surfaced. I was hoping someone here may be able to answer them. Two have
links to possible
Ühel kenal päeval, N, 2006-06-22 kell 09:59, kirjutas Mark Woodward:
After a long battle with technology, [EMAIL PROTECTED] (Mark
Woodward), an earthling, wrote:
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled into
It pointed to *ALL* the versions.
Hmm, OK, then the
Ühel kenal päeval, N, 2006-06-22 kell 10:20, kirjutas Jonah H. Harris:
On 6/22/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Hmm, OK, then the problem is more serious than I suspected.
This means that every index on a row has to be updated on every
transaction that modifies that row. Is
Ãhel kenal päeval, N, 2006-06-22 kell 09:59, kirjutas Mark Woodward:
After a long battle with technology, [EMAIL PROTECTED] (Mark
Woodward), an earthling, wrote:
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled
into
It pointed to *ALL* the versions.
Hmm, OK, then the
On 6/22/06, Hannu Krosing [EMAIL PROTECTED] wrote:
I guess that MySQL on its original storage does that, but they allow
only one concurrent update per table and no transactions.
More like practically every commercial database. As ~97% of
transactions commit (yes, some can argue that number),
Ãhel kenal päeval, N, 2006-06-22 kell 10:20, kirjutas Jonah H. Harris:
On 6/22/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Hmm, OK, then the problem is more serious than I suspected.
This means that every index on a row has to be updated on every
transaction that modifies that row. Is
Diogo Biazus [EMAIL PROTECTED] writes:
The idea I've been discussing with Simon Riggs is to create a set of
functions that can be called from within the database.
I'd question that at the very start. I don't see any strong reason to
do it that way, and as you admit further down it'd make it
Christopher Browne [EMAIL PROTECTED] writes:
After a long battle with technology, [EMAIL PROTECTED] (Mark Woodward), an
earthling, wrote:
Not true. Oracle does not seem to exhibit this problem.
Oracle suffers a problem in this regard that PostgreSQL doesn't; in
Oracle, rollbacks are quite
Mark Wong wrote:
Now why are we failing on 7.3? What version of flex do you have? If
it's too modern we'll just need to take 7.3 out of the cobra and
stoat rotations - we'd really only make supercritical fixes on that
branch these days.
Flex is 2.5.33 on both systems. I'm assuming
On 6/22/06, Mark Woodward wrote:
(..)
thousand active sessions
(..)
If an active user causes a session update once a second
(..)
Generally speaking, sessions aren't updated when they change, they are
usually updated per HTTP request. The data in a session may not change,
but the session
Tom Lane wrote:
Basically there's no free lunch: if you want the benefits of MVCC it's
going to cost you somewhere. In the Postgres design you pay by having
to do VACUUM pretty often for heavily-updated tables. I don't think
that decision is fundamentally wrong --- the attractive thing about
On 6/22/06, Tom Lane [EMAIL PROTECTED] wrote:
it'd make it impossible to use the viewer to work
on extracting data from a failed cluster; which is,
at least in my mind, one of the primary use-cases
for the thing.
While I too see this as something which could be used for this outside
the
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put some
logic in the session table that turns an update without changes into a
no-op?
err isnt that one the job of the database?
regards,
Lukas
---(end of
[EMAIL PROTECTED] (Csaba Nagy) writes:
[...]
There has to be a more linear way of handling this scenario.
So vacuum the table often.
Good advice, except if the table is huge :-)
... Then the table shouldn't be designed to be huge. That represents
a design error.
Here we have for
On 6/22/06, Tom Lane [EMAIL PROTECTED] wrote:
The Oracle design has got other drawbacks: if you need to access a row
version other than than the very latest, you need to go searching in the
rollback segments for it.
There are ways to implement this functionality without implementing it
exactly
On Thu, 22 Jun 2006 19:01:38 +0200
Lukas Smith [EMAIL PROTECTED] wrote:
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put some
logic in the session table that turns an update without changes into a
no-op?
err isnt that one the job of the
Here we have for example some tables which are frequently updated but
contain 100 million rows. Vacuuming that takes hours. And the dead row
candidates are the ones which are updated again and again and looked up
frequently...
This demonstrates that archival material and active data
Jonah H. Harris [EMAIL PROTECTED] writes:
I think it should certainly be able to run on it's own, but it
wouldn't be that hard to extend the functions so that they were usable
from within the database or vice-versa.
Yes it would. The most obvious point is that memory management and
error
Christopher Browne [EMAIL PROTECTED] writes:
After a long battle with technology, [EMAIL PROTECTED] (Mark
Woodward), an earthling, wrote:
Not true. Oracle does not seem to exhibit this problem.
Oracle suffers a problem in this regard that PostgreSQL doesn't; in
Oracle, rollbacks are quite
You mean systems that are designed so exactly, that they can't take 10%
performance change ?
No, that's not really the point, performance degrades over time, in one
minute it degraded 10%.
The update to session ratio has a HUGE impact on PostgreSQL. If you have a
thousand active
On 6/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Yes it would. The most obvious point is that memory management and
error handling conventions inside the backend are quite different from
what you'd expect to employ in a standalone program.
No, this wouldn't really be that hard, especially if he
You mean systems that are designed so exactly, that they can't take
10%
performance change ?
No, that's not really the point, performance degrades over time, in one
minute it degraded 10%.
The update to session ratio has a HUGE impact on PostgreSQL. If you have
a
thousand active
On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
I believe our supported version is still 2.5.4, which is
what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only supported flex version is 2.5.4, I think
this
Marc,
Sorry folks, my fault ... hit the 'accept' button too fast
So, was Wilbur really as attractive as she claimed?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 6: explain analyze is your friend
On 6/22/06, Rod Taylor [EMAIL PROTECTED] wrote:
If you INSERT into multiple partitions (by time -- say one per minute)
and TRUNCATE periodically (30 minute old partitions for 30 minute
expiry) it works much better. Expiring the session is quite fast as well
since they'll go away with the
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
I believe our supported version is still 2.5.4, which is
what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only
On Thu, 2006-06-22 at 13:42 -0400, Jonah H. Harris wrote:
On 6/22/06, Rod Taylor [EMAIL PROTECTED] wrote:
If you INSERT into multiple partitions (by time -- say one per minute)
and TRUNCATE periodically (30 minute old partitions for 30 minute
expiry) it works much better. Expiring the
On Thu, 22 Jun 2006, Josh Berkus wrote:
Marc,
Sorry folks, my fault ... hit the 'accept' button too fast
So, was Wilbur really as attractive as she claimed?
I don't know, Bruce mentioned to me that he wanted to meet him, so we'll
have to wait until they have their get-together :)
item #2: Is dllinit.c GPL code?
The file dllinit.c, located in the src/utils directory
documents the
author as Mumit Khan. Did Mumit Khan contribute this code
and did he
contribute it for distribution under the PostgreSQL license? If I
read correctly, the name stamp in CVS does
On Thu, 22 Jun 2006, Jonah H. Harris wrote:
On 6/22/06, Rod Taylor [EMAIL PROTECTED] wrote:
If you INSERT into multiple partitions (by time -- say one per minute)
and TRUNCATE periodically (30 minute old partitions for 30 minute
expiry) it works much better. Expiring the session is quite fast
Tom Lane [EMAIL PROTECTED] writes:
The Oracle design has got other drawbacks: if you need to access a row
version other than than the very latest, you need to go searching in the
rollback segments for it. This is slow (no index help)
Just for the record, if i understood correctly -- this
Jonah H. Harris [EMAIL PROTECTED] writes:
On 6/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Yes it would. The most obvious point is that memory management and
error handling conventions inside the backend are quite different from
what you'd expect to employ in a standalone program.
No, this
Agree, the project must choose one path as the starting point. But the two options can be given in the long run.I still think that as a starting point the functions inside the database are a good option.The reasons are:
- using SQL to agregate and transform data in any way from the logs.- it's
Greg Stark wrote:
There are other solutions too. I never used DB2 but I was led to believe they
used their transaction log to retrieve old versions of the records. Someone
else here claimed DB2 didn't implement MVCC at all so perhaps that's wrong
though.
I would be suprised giving this paper:
Lukas Smith [EMAIL PROTECTED] writes:
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put some
logic in the session table that turns an update without changes into a
no-op?
err isnt that one the job of the database?
No. That idea has been suggested and
On Thu, June 22, 2006 1:42 pm, Josh Berkus wrote:
Marc,
Sorry folks, my fault ... hit the 'accept' button too fast
So, was Wilbur really as attractive as she claimed?
In all seriousness, it's actually a pretty clever spam ploy.
1) Spam mailing lists of nerdy, desperate guys with
Tom,
Augh. Does this mean that we need to backpatch earlier versions to remove
the possible GPL links?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The Oracle design has got other drawbacks: if you need to access a row
version other than than the very latest, you need to go searching in the
rollback segments for it. This is slow (no index help)
Just for the
Diogo, are you working from my old xlogdump hack?If so what version?I can send you the latest off-list.I add stuff to it periodically when
I need it, and I don't think I've published it lately.Yup, I've got a version that was posted here some time ago. If you could send me the latest version I
Magnus Hagander [EMAIL PROTECTED] writes:
item #2: Is dllinit.c GPL code?
I don't think it's needed on Win32. It's not included in my VC++ build,
because I forgot it :-), and it works just fine.
The point is that as long as we don't do anything in it (which we
don't), the runtime supplied
As you can see, in about a minute at high load, this very simple table
lost about 10% of its performance, and I've seen worse based on update
frequency. Before you say this is an obscure problem, I can tell you it
isn't. I have worked with more than a few projects that had to switch
away
Josh Berkus josh@agliodbs.com writes:
Augh. Does this mean that we need to backpatch earlier versions to remove
the possible GPL links?
[ shrug... ] I'm not planning to panic; we've still got explicit GPL
code that's not been cleaned out of contrib/ yet. (Um, weren't you on
the hook to move
Adding back pgsql-hackers.
Mark Woodward wrote:
Mark Woodward wrote:
Hmm, OK, then the problem is more serious than I suspected.
This means that every index on a row has to be updated on every
transaction that modifies that row. Is that correct?
Add an index entry, yes.
I am
Tom,
[ shrug... ] I'm not planning to panic; we've still got explicit GPL
code that's not been cleaned out of contrib/ yet. (Um, weren't you on
the hook to move those modules to pgfoundry projects?)
Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure
As you can see, in about a minute at high load, this very simple table
lost about 10% of its performance, and I've seen worse based on update
frequency. Before you say this is an obscure problem, I can tell you it
isn't. I have worked with more than a few projects that had to switch
away
so presumably this is only needed for old Cygwin versions. Can anyone
say how old 1001 is and whether we still ought to care about it?
IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based on a quick Google. So it's definitely older than
PG 7.3.
Tom Lane [EMAIL PROTECTED] writes:
Yeah, you should be able to find the older version easily enough, if you
arrived at the newer version and realized you needed to visit the older
version. But this fails in scenarios where you are searching on a
column that's been updated --- the index
Josh Berkus josh@agliodbs.com writes:
Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure out how to generate a patch that removes directories.
Don't worry about that; CVS never deletes directories. But anyway,
I can easily handle removing the code. I
Tom,
adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock
I think you're right. I will do this before I leave town on the 30th.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
What you seem not to grasp at this point is a large web-farm, about 10 or
more servers running PHP, Java, ASP, or even perl. The database is
usually
the most convenient and, aside from the particular issue we are talking
about, best suited.
The answer is sticky sessions : each user is
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure out how to generate a patch that removes directories.
Don't worry about that; CVS never deletes directories. But anyway,
I can easily handle
On 6/22/06, Tom Lane [EMAIL PROTECTED] wrote:
Jonah, I've been working with this system for years, and it's not that
easy to handle the differences with a few macros.
True, it is harder than just that. I didn't mean to make light of it
at all, just that a good amount of design upfront would
Bort, Paul wrote:
so presumably this is only needed for old Cygwin versions. Can anyone
say how old 1001 is and whether we still ought to care about it?
IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based on a quick Google. So it's
What you seem not to grasp at this point is a large web-farm, about 10
or
more servers running PHP, Java, ASP, or even perl. The database is
usually
the most convenient and, aside from the particular issue we are talking
about, best suited.
The answer is sticky sessions : each user
PFC wrote:
What you seem not to grasp at this point is a large web-farm, about
10 or
more servers running PHP, Java, ASP, or even perl. The database is
usually
the most convenient and, aside from the particular issue we are talking
about, best suited.
The answer is sticky sessions
Tom Lane wrote:
The bad news is that except in the stats_command_string cases, HEAD
is noticeably slower than 8.1 on the machine with slow gettimeofday.
In the single-transaction test this might be blamed on the addition
of statement_timestamp support (which requires a gettimeofday per
On Thu, Jun 22, 2006 at 07:01:38PM +0200, Lukas Smith wrote:
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put
some logic in the session table that turns an update without
changes into a no-op?
err isnt that one the job of the database?
By no means.
On Jun 22, 2006, at 12:56 PM, Greg Stark wrote:
Just for the record, if i understood correctly -- this was all a
bit black
magicky -- Oracle found the data in the rollback segment by storing
a pointer
to it in the block header where the updated data is. Ie, it could jump
straight to the
On Jun 22, 2006, at 2:00 PM, Mark Woodward wrote:
I actually have a good number of years of experience in this topic,
and
memcached or file system files are NOT the best solutions for a server
farm.
What's wrong with memcached for session data?
--
Jim C. Nasby, Sr. Engineering Consultant
On Jun 22, 2006, at 1:09 PM, Tom Lane wrote:
Lukas Smith [EMAIL PROTECTED] writes:
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put some
logic in the session table that turns an update without changes
into a
no-op?
err isnt that one the job of the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
This is what I get on a fast AMD Dual Opteron box(Running Debian
Sarge/AMD64):
8.1.4 HEAD
100 SELECT 1; 74,74,7377,76,77
stats_command_string=1; 105,99,106
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
This is what I get on a fast AMD Dual Opteron box(Running Debian
Sarge/AMD64):
8.1.4 HEAD
100 SELECT 1;74,74,7377,76,77
stats_command_string=1;
Jim Nasby [EMAIL PROTECTED] writes:
Question: do we currently create new index entries even if the index
key hasn't changed?
Yes.
If so, what's the purpose of storing the CTID of
the next version in the old version of the row?
So that UPDATE can always find the newest version of the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Or do you mean that you have stats_row_level and/or stats_block_level on
in all four cases?
yes - stats_row_level and stats_block_level on in all cases (sorry for
the confusion) - I can easily redo the tests without those - but
Andrew Dunstan [EMAIL PROTECTED] writes:
Bort, Paul wrote:
so presumably this is only needed for old Cygwin versions. Can anyone
say how old 1001 is and whether we still ought to care about it?
IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based
Jim Nasby [EMAIL PROTECTED] writes:
What would be nice to add is the ability to perform that check more
easily. As of 8.1...
...
if NEW=OLD then
...
ERROR: operator does not exist: test = test
HINT: No operator matches the given name and argument type(s). You
may need to add explicit
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Or do you mean that you have stats_row_level and/or stats_block_level on
in all four cases?
yes - stats_row_level and stats_block_level on in all cases (sorry for
the confusion) - I can easily redo the tests
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
It'd be interesting to compare 8.1 and HEAD for the no-overhead case;
I don't think you need to redo all four cases, but I'd like to see that one.
8.1: 50,50,49
HEAD: 49,48,49
OK, so that seems comparable to my results on a
Tom Lane wrote:
Charles Comiskey [EMAIL PROTECTED] writes:
item #3: Carsten Wolff copyright in informix.c file
The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?
Wow, I see what mess we would be into if we
Josh Berkus wrote:
Tom,
adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock
I think you're right. I will do this before I leave town on the 30th.
before anyone asks, the files I wrote in contrib/mac are free to be licensed
any way the
project sees fit.
Tom Lane wrote:
OK, so let's yank the file altogether and see what happens.
I can make a cut at fixing the makefiles based on removing references to
DLLINIT, but it might be better if someone who's in a position to test
the results on Windows did the patch ...
Something has
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
It'd be interesting to compare 8.1 and HEAD for the no-overhead case;
I don't think you need to redo all four cases, but I'd like to see that
one.
8.1:50,50,49
HEAD: 49,48,49
OK, so that
Andrew Dunstan wrote:
Tom Lane wrote:
OK, so let's yank the file altogether and see what happens.
I can make a cut at fixing the makefiles based on removing references to
DLLINIT, but it might be better if someone who's in a position to test
the results on Windows did the patch ...
1 - 100 of 122 matches
Mail list logo
