Joshua D. Drake wrote:
Michael Paesold wrote:
I would also add another sentence about *why* the recommendation was
changed. We have one rule-based setup here, and it has been working
flawlessly for us,... so personally I don't even know the reasons.
Rules are extremely slow in compar
* the recommendation was
changed. We have one rule-based setup here, and it has been working
flawlessly for us,... so personally I don't even know the reasons.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 1: if posting/reading thro
code is
really unsafe?
We usually *round* all values to at maximum 4 decimal places -- are we
on the save side? Does this only affect high precision division, or any
divisions?
Best Regards
Michael Paesold
Bruce Momjian wrote:
Because this has not been applied, this has been saved for th
r saw problem,
perhaps because we round to very few digits, but well.
Please apply this patch. I can accept the performance drop, as long as
there won't be bad surprises with correctness.
Best Regards
Michael Paesold
---(end of broadcast)---
tch status says "waiting on update from author":
http://archives.postgresql.org/pgsql-patches/2007-04/msg00331.php
Any updates on this?
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 6: explain analyze is your friend
to protect the POSIX segment.
Best Regards
Michael Paesold
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
quot;event [ OR ... ]" notation.
Best Regards,
Michael Paesold
For quick reference:
http://momjian.us/main/writings/pgsql/sgml/sql-createconstraint.html
Index: create_constraint.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/cr
.
Additionally, I would prefer "Use this assigned name when dropping the
trigger." here, because this one confused me to try to "ALTER TABLE DROP
CONSTRAINT" instead of "DROP TRIGGER".
Thanks again.
Best Regards,
Michael Paesold
---(e
riginal query string, PREPARE stripped
or not.
This comment is based on my assumption -- hopefully correct -- that the
querytree has indeed changed from the original query. E.g. removed redundant
parenthesis, added casts, etc.
Best Regards,
Michael Paesold
---(end of b
cause
it cost too much time. Perhaps someone else wants to step up to maintain
such a list, not as detailed as the release notes probably.
Just my two (Euro)cents.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Have y
quot;.
See e.g.:
http://sourceforge.net/projects/libedit/
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html
IMHO libreadline does not sound good.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner wil
is the best solution people can
agree on, better now than later. The missing dependencies for sequences
were a bug in the first place, IMHO.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
uld write some.
Best Regards,
Michael Paesold
psql.patch
Description: Binary data
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ion number for easy navigation.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
our and many
other production databases. I suggest that should be a plain VACUUM.
Otherwise I think you have done great job finally integrating auto vacuum
into the backend.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: if
ot;vacuum_cost_delay" because it turns cost-based vacuum delay on or off. I
believe not many will have vacuum_cost_delay enabled in postgresql.conf, but
will want to enable it for autovacuum.
At least I do.
Best Regards,
Michael Paesold
---(end of broadcast)
the former.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
nd because it's not too far off.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
option 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 3: if posting/readi
essing
(CopyGetData())")));
+
This can't stay like it is, can it?
Who uses the old FE protocol for COPY? Any drivers?
Otherwise I think the speed improvment is very fine. :-)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
t's outside any
spec anyway, but I do think we ought to think twice about adding this
to SQL literal handling.
+1 from me on this for Tom -- please don't break spec compliance!
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 7:
Richard Huxton wrote:
Michael Paesold wrote:
But people (like me for example) will want to enable this behaviour by
default. So they (me too) will put the option in .psqlrc. It is then
enabled "by default". But then many of my scripts will destroy data
instead of just erroring out.
I
to put savely into .psqlrc (what some people will want, I have \set
AUTOCOMMIT off in my .psqlrc file, too, and I know I am not the only one)
* another one that will also work in scripts
I hope you understand and accept the issue here.
Best Regards,
Michael Paesold
-
Bruce Momjian wrote:
Michael Paesold wrote:
Some suggestions in random order:
* I think you should use PSQLexec instead of using PQexec directly.
PSQLexec
is used by all \-commands and prints out queries with -E, which is very
helpful for debugging.
-E display queries that internal
t...
The current way is ok for me at the moment. I still think there is a better
way (parsing statements like it's already done for
no-transaction-allowed-statements), but hey, as soon as your patch will be
applied, I can myself propose another patch to improve this. ;-)
Best Regards,
Michael
mented a way to savely put \reseterror in .psqlrc. I
previously suggested an AUTO setting (additional to ON/OFF) that disables
\reseterror when reading from a non-tty. So putting \reseterror AUTO in
.psqlrc would be save.
Otherwise, I could not find a way to break it. :-)
Bes
Alvaro Herrera wrote:
>Michael Paesold wrote:
Alvaro suggested to implement such a function. It is not there yet. I
think
you would have to access the sub xact stack, but I have not looked into
that code for quite some time.
http://archives.postgresql.org/pgsql-general/2004-10/msg00370.php
Greg Sabino Mullane wrote:
Michael Paesold wrote:
2) Implement a server-side function to get the savepoints from the server
and query that before every release.
I could not find a way to do this. Is there any interface to the list?
Alvaro suggested to implement such a function. It is not there yet
the savepoints from the server
and query that before every release.
What do you think?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEm
Neil Conway wrote:
On Tue, 2005-01-25 at 16:49 -0700, Ed L. wrote:
The attached dbsize patch:
+ makes relation_size(relname) include toast tables;
+ adds aggregate_relation_size(relname) to count table data and indices;
+ adds indices_size(relname) to report the size of indices for a
relation;
I'
ITAGAKI Takahiro wrote:
I think that there is room for improvement in WAL.
Here is a patch for it.
I think you should resend your patch as a context diff (diff -c). Otherwise
it's hard to see what your patch does.
Best Regards,
Michael Paesold
---(end of broa
covery, but replaying the logs from the whole
benchmark session)
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
for analyze also. ISTM that there
is also no distinction between VACUUM and VACUUM FULL, but I think
pg_autovacuum never does a vacuum full, so there is no problem with that.
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 8: explain
not using it, would it?
Best Regards,
Michael Paesold
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> One potential problem I see with the patch is that it opens lots of
> >> savepoints but does not release any.
>
> > Well, given that EXCEPTION blocks in Pl/pgSQL and
Alvaro Herrera wrote:
> On Tue, Sep 21, 2004 at 02:30:17PM +0200, Michael Paesold wrote:
> > http://archives.postgresql.org/pgsql-hackers/2004-09/msg00576.php
>
> One potential problem I see with the patch is that it opens lots of
> savepoints but does not release any. I
if they are used to oracle, mssql etc. At least at the
interactive level, the patch would give them the option to have their
accustomed way of handling e.g. typos.
Thank you for your time and thank you for any response!
Best Regards,
Michael Paesold
P.S. attached is a version of the patch with
I wrote:
> Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?
I don't know how I did it, but this was the wrong patch. Correct patch
attached now.
Best Regards,
MIchael Paesold
variables.c.diff
Description: Binary data
---(end of b
don't know
if the case sensitivity is needed.
Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?
Best Regards,
Michael Paesold
psql-autocommit.diff
Description: Binary data
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
> Tom Lane wrote:
>
> > > It is now fixed in the attached patch.
> >
> > Applied with some additional cleanup (the code wasn't multibyte-aware,
> > and so could get fooled in some Far Eastern encodings).
Looking at your cleanup is a good for learning more about C. :-)
But I have one another que
Tom Lane wrote:
> > It is now fixed in the attached patch.
>
> Applied with some additional cleanup (the code wasn't multibyte-aware,
> and so could get fooled in some Far Eastern encodings).
I am very pleased to hear. This was my first patch submitted. :-)
Best Rega
Michael Paesold wrote
> Tom Lane wrote:
> > Per SQL spec, the backend thinks that /* .. */ nests:
> >
> > regression=# /* some /* comment */ comment */ select 1;
> > ?column?
> > --
> > 1
> > (1 row)
> >
> > As it stands,
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > Or do I not understand what you mean by nested
> > comments? (There is code for ignore /* .. */ before the first keyword.)
>
> Per SQL spec, the backend thinks that /* .. */ nests:
>
>
y suggestion how to that? I can think of a way myself, but it may not be
the best, as I don't consider C my natural language. I can try, or does
anyone else feel inclined to fix this?
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
suggest the attached fix. is_transact_command() in
src/bin/psql/common.c is used to determine if a command is a transaction
modifying command. The diff just adds "vacuum" to those commands, so that
psql will not issue a BEGIN before a VACUUM.
Best Regards,
Michael Paesold
psql-autocommit-v
45 matches
Mail list logo
