Andrej Ricnik-Bay wrote:
Has anyone here seen this one before? Do the values
appear realistic?
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
Some of the particularly bad test results for PostgreSQL may be related
to using the default memory configuration and never having run ANALYZE.
On Sat, Feb 11, 2006 at 09:21:43PM +0100, Jochem van Dieten wrote:
On 2/11/06, Andrej Ricnik-Bay wrote:
Has anyone here seen this one before? Do the values
appear realistic?
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
The values appear to originate from an intrsinsically
Mark Woodward wrote:
I know this is a kind of stupid question, but postgresql does not
behave well when the system changes in a major way without at least
an analyze. There must be something that can be done to protect the
casual user (or busy sometimes absent minded developer) from these
Mark Woodward wrote:
My question was based on an observation that ANALYZE and VACUUM are
nessisary, both for different reasons. The system or tools must be
able to detect substantial changes in the database and at least run
analyze if failing to do so would cause PostgreSQL to fail badly.
Mark Woodward wrote:
My question was based on an observation that ANALYZE and VACUUM are
nessisary, both for different reasons. The system or tools must be
able to detect substantial changes in the database and at least run
analyze if failing to do so would cause PostgreSQL to fail badly.
On 2/11/06, Andrej Ricnik-Bay wrote:
Has anyone here seen this one before? Do the values
appear realistic?
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
The values appear to originate from an intrsinsically flawed test setup.
Just take the first test. The database has to do 1000
Kenneth Marshall [EMAIL PROTECTED] writes:
If the heads of the disk are in the right location, you could easily do
more than 1 commit per disk revolution so the values over 2 seconds could
actually be valid. 9 seconds would be worst case of 1 commit per revolution.
No, because a commit in PG
Peter Eisentraut [EMAIL PROTECTED] writes:
Yes, that is what autovacuum does. It detects changes in the database
and runs analyze if failing to do so would cause PostgreSQL to behave
badly. I don't know why it's not turned on by default.
Conservatism. It may well be on by default in some
On Fri, 2006-02-10 at 17:46 +, Simon Riggs wrote:
Lastly, there isn't any obvious reason that I can see for having to
change the default assumption about cursors. Most queries don't go
through cursors. For those that do, we already document that specifying
NO SCROLL can be a
if we had a pg_vacuum table that had the last timestamp of a vacuum/analyze for
each table and the stats looked like
the default, why not just print a warning message out to the user?
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Peter Eisentraut [EMAIL
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
What do you think of my earlier suggestion. Skip all the 'create function' statements and
just add the AS 'filename' LANGUAGE C to the CREATE TYPE.
Very little, as it makes unjustifiable assumptions about all the
datatype's
On Sun, Feb 12, 2006 at 07:33:30PM +0100, Thomas Hallgren wrote:
Very little, as it makes unjustifiable assumptions about all the
datatype's support functions being predictably propertied. (There's
more than one possible signature, let alone any secondary properties
such as volatility or
I have updated the 8.1.X documentation to remove the word only, which
is confusing.
---
Jim C. Nasby wrote:
On Thu, Feb 09, 2006 at 10:37:34AM +0100, Csaba Nagy wrote:
option can only be set at server start or in
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Is this something we need for 8.1.X?
---
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon
Martijn van Oosterhout wrote:
The docs are your friend, see[1] in particular the input_function and
the receive_function.
[1] http://www.postgresql.org/docs/8.1/interactive/sql-createtype.html
Ok, so there are two 'optional' arguments. Following my suggestion, the
input and receive
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Is this something we need for 8.1.X?
Personally, I think it's a bug which should be fixed. I don't think
everyone agrees on that though and there are some parts which could be a
bit controversial. The main issue is that now the entire Kerberos
Then the patch safest for just 8.2 then.
---
Stephen Frost wrote:
-- Start of PGP signed section.
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Is this something we need for 8.1.X?
Personally, I think it's a bug
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Then the patch safest for just 8.2 then.
My hope is to come up with a better patch which will be acceptable for
both 8.1.x and 8.2.. I'll try and come up with something this week. I
don't think it's a huge issue if it's not in 8.1.3 tho.
OK, yea, it is inconsistent. I changed it do throw a warning instead.
Only patched to 8.2 because it is a behavior change.
---
Kris Jurka wrote:
Why is latin1 special in its conversion from unconvertible unicode data?
I think we've talked about this a couple times over the years, but I'm not
sure it was resolved or not.
The message post about load testing and SQLite showed PostgreSQL poorly.
Yea, I know, it was the Windows port not being optimized, I can see that,
but it raises something else. A good set of
In case you missed it:
In 8.2 the settings initdb makes as a default for shared_buffers and
max_fsm_pages will be significantly higher if the machine can stand it.
This should have some good performance impact on the out of the box
configuration.
Frankly - supplying more sample configs is
Added to TODO:
o Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another
solution would be to reverse lookup the connection IP and
Would the easiest solution be to make a patch to readline for Win32, and
only allow Win32 to link to readline if that patch is in readline, and
spit out a compile error if readline doesn't have that patch.
As far as the license, psql spits out a copyright notice as it starts.
It would be a
I would like to work on TODO item - Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)Any suggestion / comments ?ThanksK. Manikandan
mani [EMAIL PROTECTED] writes:
I would like to work on TODO item - Allow INSERT INTO tab (col1, ..) VALUE=
S
(val1, ..), (val2, ..)
Any suggestion / comments ?
If you look at the SQL spec, INSERT/VALUES is actually just a special
case --- VALUES is supposed to be a table construct that can be
26 matches
Mail list logo
