a different mirror' that resets
or ignores the cookie.
If I had a vote, I would vote +1 for this option. I think it's easy to
implement and shouldn't have negative effects on performance.
Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can
Hi,
I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
In a PL/pgSQL function I want to insert into a table and get the OID back.
That usually works with
GET DIAGNOSTICS last_oid = RESULT_OID;
right after the insert statement.
But if the table that I insert to has a rule (or
Hi,
I am wondering about bad INSERT performance compared against the speed of
COPY. (I use 7.2.2 on RedHat 7.2)
I have a table with about 30 fields, some constraints, some indexes, some
foreign key constraints. I use COPY to import old data. Copying about
10562 rows takes about 19 seconds.
For
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I have come across a problem (bug?) with PL/pgSQL GET DIAGNOSTICS.
Hm. This seems to be SPI's version of the same definitional issue
we're contending with for status data returned from an interactive
query: SPI is currently set up
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
To insert another 10562 rows takes about 12 minutes now!!!
See
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/populate.html
particularly the point about not committing each INSERT as a separate
transaction.
regards
analyze; helps
analyze tablename; of table that I insert to doesn't help!
analyze tablename; of any table reference in foreign key constraints
doesn't help!
Only vacuum will reset the insert times to the lowest possible!
What does the vacuum code do?? :-]
Regards,
Michael Paesold
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Only vacuum will reset the insert times to the lowest possible!
What does the vacuum code do?? :-]
It removes dead tuples. Dead tuples can only arise from update or
delete operations ... so you have not been telling us the whole
1;
RETURN ret + 1;
END;
' LANGUAGE 'plpgsql';
Using that is nearly as fast as a regular sequence.
Thanks to all of you for your help.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
different users per database, so that it doesn't
matter if the proposed restriction setting is by database or by user.
Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
This document:
http://developer.postgresql.org/docs/postgres/release-7-2-3.html
mentions a release date of 2002-10-01 for version 7.2.3.
It isn't on the main website, tough, is it?
Regards,
Michael
---(end of broadcast)---
TIP 2: you can get
Justin Clift [EMAIL PROTECTED] wrote:
Hi Michael,
Michael Paesold wrote:
snip
Hi Justin,
I am from Austria, and I would like to help. I could provide a German
translation. The Babelfish's translation is really funny. Machine
translation is readable, but it is no advocacy. ;-) I do
Tino Wildenhain [EMAIL PROTECTED] wrote:
Hi Justin,
Good point. For the moment we've whipped up that MS Excel document
(created in OpenOffice of course) of all the English text strings in the
site and emailed it to the volunteers. :)
Btw. did you ever unzip the native OpenOffice (aka
Mike Mascari [EMAIL PROTECTED] wrote:
I can't test the use of CURRENT_TIMESTAMP because I have Oracle
8, not 9.
What about NOW()? It should be available in Oracle 8? Is it the same as
SYSDATE?
Regards,
Michael Paesold
---(end of broadcast
Mike Mascari [EMAIL PROTECTED] wrote:
Michael Paesold wrote:
What about NOW()? It should be available in Oracle 8? Is it the same as
SYSDATE?
Unless I'm missing something, NOW() neither works in Oracle 8
nor appears in the Oracle 9i online documentation:
http://download
do not really nead an
interface, but just tell me in what way you want the texts.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere
. are converted to now()::TIMESTAMP, at least in 7.2,
right?
So when there are all three options available, it would be easy to change
the behaviour of CURRENT_DATE/TIME/TIMESTAMP, right?
SET .. or GUC would be options, no?
Best Regards,
Michael Paesold
---(end of broadcast
CURRENT_TIMESTAMP. What do you think
about read-commited level? Can time be commited? ;-)
It would be even more surprising to new users if the implementation of
CURRENT_TIMESTAMP would depend on trx serialization level.
Regards,
Michael Paesold
---(end of broadcast
. That is an inherent problem with read-commited though and has not so
much to do with the timestamp behavior.
Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
setup to be
unreliable or bad performing.
I'll see.
Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Lists.
What do I need to send now?
Marc?
it is:
set ALL unique your-email
if you also don't want to get emails that have already been cc'd to you, you
can use:
set ALL eliminatecc your-email
for a full list of set options send:
help set
to majordomo.
Regards,
Michael Paesold
a
performance point of view, this would only be good if each transaction
log had it's own disk. Otherwise a single transaction log is still better.
I think tablespaces is a good idea. I also prefer associating tablespaces
with directory structures better over the oracle style.
Regards,
Michael Paesold
Tom Lane [EMAIL PROTECTED] wrote:
Michael Paesold [EMAIL PROTECTED] writes:
In a PL/pgSQL function I want to insert into a table and get the OID
back.
That usually works with
GET DIAGNOSTICS last_oid = RESULT_OID;
right after the insert statement.
But if the table that I insert
bison (GNU Bison) 1.35
Although I am not a hacker, I think you just need to upgrade
bison to version 1.75 if you want to build from CVS. The ecpg
interface is broken with version 1.35 of bison.
Best Regards,
Michael Paesold
---(end of broadcast
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Basically, total connections is to be set larger than you think you will
ever need, while you expect per-db to be hit, and if something keeps
trying to connect and failing, we may get very bad connection
user would have their own database and
only pg_xlog shared -- that part seems tricky as you said before.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
LEVEL
-
READ COMMITTED this should be SERIALIZABLE, no??
(1 row)
billing=# commit;
COMMIT
Is it a bug?
Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
about this all?
Best Regards,
Michael Paesold
-- logfile:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'bench_big_pkey' for table 'bench_big'
DEBUG: recycled transaction log file 009F
[...skipping: recycled transaction log file 00A0 to
00AE
Michael Meskes wrote:
Hi,
is a pl/pgSQL function completely parsed once? Or is only the next
statement parsed as with many interpreters? If it's the latter it would
mean one has to run each branch just to see if the syntax is correct. Is
that true?
Michael
If the docs are true, than
on a laptop or
desktop system, I would suggest that this is classified as a convenience
bug and fixed in a reasonable way.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
that time
Is there currently debug output in the code that could tell me answers to
those questions? If so, I could try to some testing.
Jan, you're probably the only one who's done any serious testing of
alternatives for this --- what do you think?
Best Regards,
Michael Paesold
(now default 1)
bgwriter_maxpages = 200 (now default 100)
Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
zone
information is irrelevant for me in server logs.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
as a convenience
bug and fixed in a reasonable way.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 8: explain analyze is your friend
really suggest to change to standard compliance.
Best Regards,
Michael Paesold
P.S. I know that there is still the problem of shared memory growth because
of the transaction id locks, but lets focus on one problem at a time :-).
---(end of broadcast
directly... will there are still the other languages.
I just wanted to show that it is still not _that_ save to use colliding
savepoint names.
Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose
my proposal to be incorrect, because an implicit
RELEASE SAVEPOINT a; has side effects that are definitively against the
standard or what you would expect.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: the planner will ignore your
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
On the other hand, the scenario of a psql option (read: I have
given up the idea of a backend implementation) to rollback only
last statement on error is quite different.
Sure (and we already have one for autocommit). But I
I was having the best TPC-C results with.
And how were the default values in chosen? Educated guesses?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
is that this is currently not possible, since bgwriter_delay has
an upper limit of 5 seconds. Tom said this could be fixed.
Perhaps add as open item?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
permanently is to stop
...
Comments?
Well, I am not able to comment here, but I can say I usually trust your
judgement.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
Andreas Pflug wrote:
W. Europe Daylight Time on my system.
With my german system it is Westeuropäische Sommerzeit.
which is longer then the actual timestamp:
2004-09-26 11:56:55
Westeuropäische Sommerzeit
Any fix is appreciated!
Best Regards,
Michael Paesold
---(end
this is what I made a patch for, so shouldn't it be back for 8.1?
Or at least something similar?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
(8.0 beta).
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
will have been fsynced already
and everything else will be in WAL.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
in pg_autovacuum that will set
vacuum_cost_delay before executing vacuum. So one can leave
vacuum_cost_delay at zero in postgresql.conf, but enable it for background
vacuum in pg_autovacuum.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't
Greg Stark wrote:
In Postgres CREATE TABLE AS is currently being treated as a synonym for
SELECT
... INTO ... So I think this may be an awkward feature to add. Also, like
reindex the logging would still be necessary for online backups. So this
may
be a dead-end direction in the long term.
Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
Also,
like roots home directory in
/root,... would you exclude that from backups?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
? For many people it will be hard work to type the subquery to get
the database oid.
I vote for all (possibly corrected) functions to be moved into core.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
Andreas Pflug wrote:
Michael Paesold wrote:
Andreas Pflug wrote:
For the second, please supply a patch that moves _all_ of dbsize into
the main server. I think we have agreement on that.
I don't think so. As I mentioned, those views are broken. Do you want
them to be in core anyway
wothwhile, I wouldn't argue with it's
inclusion.
Well, I don't feel this is really bloat. I have been using them since the
creation of the contrib module and have found them quite useful.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 8
.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
with PITR turned on there are no
non-WAL-logged index
and table builds. Therefore the indexes and tables are WAL-logged and will
be recreated correctly.
I hope this is correct information :-)
Best Regards,
Michael Paesold
---(end of broadcast
) + indexes. If it would be called pg_table_size(), that would be ok.
We should have one with oid and another with text.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
DEFINER functions seem dangerous. I
would follow Stephen's idea that SECURITY DEFINER functions should only be
creatable/modifiable by superusers.
This would be similar to unix, where setting the suid/sgid bits is usually
only allowed to root.
Best Regards,
Michael Paesold
necessairly
something you'd want to do.
Right, that's an issue. But since the new role will be the *owner* of the
object, it *should* really have create-privileges in that schema. So the
above way seems to be correct anyway.
Best Regards,
Michael Paesold
---(end
to pg_dump
is certainly easier)
You forgot to document the long option, I think.
Are the man pages generated from the sgml docs? Have never had a look at
that.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't forget to increase
it's not too far off.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ganged wal writes or something similar. Tom, can you
elaborate on this? Please tell me if I am totally off track. ;-)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 8: explain analyze is your friend
optimization. I *guess* it could be done, with
some restrictions.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
and performance (Neil)
- Replace rtree index code with code from /contrib/rtree_gist (Tom)
So first Neil improved the performance for rtree, then rtree was
replaced with rtree_gist? So Neil's optimizations are gone?
What file should I send patches against next time? ;-)
Best Regards,
Michael Paesold
lists (possibly
newer versions of the same software?) is a Cancel message link in the
e-mail telling about moderation status.
So one can cancel the message, subscribe to the list and send the message
again.
At least better than what we have now.
Best Regards,
Michael Paesold
its 23-28 with N1. 8.1 is clearly the winner here. Great
work, Tom.
I hope some more data helps.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
tomorrow morning (CEST, i.e. in about 11 hours).
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
%)
(worse again)
CS rate was low (20-50) for all tests, increasing for N2 which has to be
expected. For this system I see no case for applying these patches.
Is there a portable way to detect the CPU we are running on? Do you have any
other idea how to implement the delays?
Best Regards,
Michael
:
ERROR: syntax error at or near , at character 237
LINE 9: credit_cursor CURSOR (p_account integer, p_reference integ...
The same function works perfectly well in 7.4.8 and 8.0.3.
A bug?
Best Regards,
Michael Paesold
---(end of broadcast
Tom Lane wrote:
But the cmpb instruction in the 8.0 version of TAS would have done that,
and I think we've already established that the cmpb is a loss on most
machines (except maybe single-physical-CPU Xeons).
Note that this was a regular Pentium 4 system, not a Xeon.
Best Regards,
Michael
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
To have other data, I have retested the patches on a single-cpu Intel P4
3GHz w/ HT (i.e. 2 virtual cpus), no EM64T. Comparing to the 2,4
dual-Xeon
results it's clear that this is in reality only one cpu. While the
runtime
for N=1
this setting because it will make the results incomparable, but it
should improve overall performance.
See
http://archives.postgresql.org/pgsql-hackers/2005-07/msg01004.php
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions
,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
: credit_cursor CURSOR (p_account integer, p_reference integ...
The same function works perfectly well in 7.4.8 and 8.0.3.
A bug?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire
the same result. If so I could
try to run with oprofile if you can give me a quick start.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
gives are correct nevertheless.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
on
pgfoundry. pgxs should work.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
guess, where
the default installation directory contains PostgreSQL.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
a marketing statepoint -- having
back branches supported for a visible amount of time increases people's
confident in PostgreSQL and it's stability.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
am not sure how easy that is considering
schema.sequence.nextval.
Just a thought.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
, this is a better URL:
http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html#RELEASE-8-1
Btw. I think the header Add proper sequence function dependencies for
DEFAULT is in the wrong font, i.e. it's all monospace.
Best Regards
Michael Paesold
---(end
. for the next major bug fixes)
is not the correct answer here. IMHO, the latest released version should be
known best in all components.
Best Regards,
Michael Paesold
Bruce Momjian wrote:
Michael Fuhr wrote:
On Thu, Oct 13, 2005 at 09:49:20AM -0600, Michael Fuhr wrote:
ecpg in 8.0.4 seems
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Can you remember regressions in stable branches in the past?
Yes. Relax. If this were a data-corruption-in-the-backend issue,
I might feel that it mandates an immediate re-release. But it isn't
and it doesn't. You'll note
the old behavior useful, while what we had before would at least
let people switch back and forth.
I think Robert is right here and the new behaviour is a step backwards.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful, while what we had before would at least
let
Bruce Momjian wrote:
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I get
a regression failure in the interval tests. I am no export for the
interval type, but the expected 9 days 28 hours seem wrong, don't
they? The actual value seems to be the same.
Is it possible that this is broken on the
Michael Glaesemann wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected 9 days 28 hours seem wrong,
don't
Michael Paesold wrote:
On Nov 7, 2005, at 17:24 , Michael Paesold wrote:
Using both PostgreSQL 8.1.0 and CVS current of Nov 7, 9:00 am CET I
get a regression failure in the interval tests. I am no export for
the interval type, but the expected 9 days 28 hours seem wrong,
don't
,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
for the record (and those interested): using 'CFLAGS=-O2
-mcpu=pentium4 -march=pentium4 -mfpmath=sse -msse2' actually passes the
regression tests.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
I wrote:
Michael Paesold [EMAIL PROTECTED] writes:
I am definatly not going to use -march=pentium4 in any production
system. Should I open a bug report with RedHat (gcc vendor)?
Yeah, but they'll probably want a smaller test case than Postgres fails
its regression tests
nor writers will block waiting.
So only if you do full table locks in your application (using LOCK TABLE
statements), you will suffer from pg_dump backups.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list
Martijn van Oosterhout wrote:
What distribution? I've never seen this postgres database you speak
of. It certainly not on any systems I've used.
It's new in 8.1 and is used as the default connection database for createdb,
etc.
Best Regards,
Michael Paesold
---(end
line.
This does not work, if the postgres database is dropped in 8.1:
psql -l template1
psql -l -d template1
of course psql template1 will just work fine.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: Don't 'kill -9
behaviour.
Please don't rush out untested core components, and perhaps think about the
people who are quite comfortable with ARC (e.g. us guys in Europe over
here).
If ARC replacement can be done in a 8.0.* release, it doesn't have to be now
in a rush, does it?
Best Regards,
Michael Paesold
almost up to the same as linux.
The original patch did not have any documentation. Have you added some?
Since this has to be configured in GUC (wal_sync_method), the implications
should be documented somewhere, no?
Best Regards,
Michael Paesold
---(end of broadcast
Magnus Hagander wrote:
Magnus Hagander wrote:
Magnus prepared a trivial patch which added the O_SYNC flag
for windows and mapped it to FILE_FLAG_WRITE_THROUGH in
win32_open.c.
[snip]
Michael Paesold wrote:
The original patch did not have any documentation. Have you
added some? Since this has
, but not in postgresql.conf.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Bruce Momjian wrote:
Michael Paesold wrote:
Magnus Hagander wrote:
[snip]
Michael, I am not sure why you come to the conclusion that open_sync
requires turning off the disk write cache. I saw nothing to indicate
that in the thread:
I was just seeing his error message below...
http
1 - 100 of 183 matches
Mail list logo
