On Wed, 2004-12-01 at 02:48, Neil Conway wrote:
I noticed that we have a bottleneck in aggregate performance in
advance_transition_function(): according to callgrind, doing datumCopy()
and pfree() for every tuple produced by the transition function is
pretty expensive. Some queries bare this
On Wed, 2004-12-01 at 08:25 +, Simon Riggs wrote:
I'd be a little twitchy about new memory contexts at this stage of beta,
but if the code is fairly well isolated that could be good.
This would be for 8.1 anyway.
Would it possible to differentiate between well-known builtin functions
and
On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
David Parker wrote:
I've been using log_min_duration_statement = 0 to get durations on all
SQL statements for the purposes of performance tuning, because this logs
the duration on the same line as the statement. My reading of this TODO
is
Tom Lane wrote:
Wrapping each individual SPI command in a subtransaction IN NO WAY
prevents us from adding programmer-controllable savepoint features
to the PL languages later.
Ah good - I was coming to the conclusion savepoints/exception handling
were both separately necessary.
It simply
alex yap wrote:
Hi,
recently i need to use pg in my project. everything going ok till
when i want to createdb it appear this :
Warning : could not remove database directory
/var/postgresql/data/base/17147 Detail: Failing system command was
: rm -rf '/var/postgresql/data/base/17147' Error: could
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's predictable and
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
Regards,
Thomas Hallgren
---(end of
Thomas Hallgren wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
It feels more distinct to me. I'll grant you I'm only a
On Wed, 2004-12-01 at 08:37, Neil Conway wrote:
On Wed, 2004-12-01 at 08:25 +, Simon Riggs wrote:
I'd be a little twitchy about new memory contexts at this stage of beta,
but if the code is fairly well isolated that could be good.
This would be for 8.1 anyway.
Would it possible to
On Wed, 01 Dec 2004 10:29:17 +0100, Thomas Hallgren
[EMAIL PROTECTED] wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
On Wed, Dec 01, 2004 at 10:03:40AM +, Simon Riggs wrote:
Please shave 20% off everybody's aggregation queries, ugly or not.
You'll see a lot of happy people.
When would the experimentation end, and 8.0 be finally released?
There's real development waiting only for release to happen ...
I
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then
On Wed, Dec 01, 2004 at 09:33:18 +,
Chris Green [EMAIL PROTECTED] wrote:
On Wed, Dec 01, 2004 at 02:02:41AM -0600, Bruno Wolff III wrote:
On Mon, Nov 29, 2004 at 12:49:46 +,
Chris Green [EMAIL PROTECTED] wrote:
This is a perpetual problem, if people all used the same MUA
Jan Wieck wrote:
This all would mean that however deeply nested a function call tree,
it would unwind and rollback everything up to the outermost catch. If
there is no catch used, no subtransactions are created and the
unwinding goes all the way up to the statement. If catch is used but
no spi
Bruno Wolff III [EMAIL PROTECTED] writes:
It is also possible for mailing list software to handle this
preference for you (by not sending copies to addresses on the list
that appear in the recipient headers), but I don't know if the
software in use has that capability.
That's a good point.
Manfred Spraul wrote:
Bruce Momjian wrote:
Comments? This seems like our only solution.
This would be a transparent solution. Another approach would be:
- Use the old 7.3 approach by default. This means perfect backward
compatibility for single-threaded apps and broken
Simon Riggs wrote:
On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
David Parker wrote:
I've been using log_min_duration_statement = 0 to get durations on all
SQL statements for the purposes of performance tuning, because this logs
the duration on the same line as the statement. My
In postgres, how do I find out how many connections are allowed per
user? Where those connections are stored? Who has the connections? Etc.
Kenny Cason
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
How difficult would it be to make the combination
log_statement = all
log_duration = true
just put the duration on the same line as the statement? Then
log_min_duration_statement could be used to
do the desired log-at-threshold behavior, which certainly seems
valuable. You'd need a way to
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
David Parker wrote:
How difficult would it be to make the combination
log_statement = all
log_duration = true
just put the duration on the same line as the statement? Then
log_min_duration_statement could be used to
do the desired log-at-threshold behavior, which certainly seems
On Wed, 2004-12-01 at 11:47, Bruce Momjian wrote:
David Parker wrote:
How difficult would it be to make the combination
log_statement = all
log_duration = true
just put the duration on the same line as the statement? Then
log_min_duration_statement could be used to
do the
On Wednesday 01 December 2004 03:38, Simon Riggs wrote:
On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
David Parker wrote:
I've been using log_min_duration_statement = 0 to get durations on
all SQL statements for the purposes of performance tuning, because this
logs the duration on
On Wednesday 01 December 2004 04:12, Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then
--- Jan Wieck [EMAIL PROTECTED] wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing
here afaict) in a
Alvaro Herrera [EMAIL PROTECTED] wrote on 01.12.2004, 15:08:11:
On Wed, Dec 01, 2004 at 10:03:40AM +, Simon Riggs wrote:
Please shave 20% off everybody's aggregation queries, ugly or not.
You'll see a lot of happy people.
When would the experimentation end, and 8.0 be finally
Robert Treat wrote:
On Wed, 2004-12-01 at 11:47, Bruce Momjian wrote:
David Parker wrote:
How difficult would it be to make the combination
log_statement = all
log_duration = true
just put the duration on the same line as the statement? Then
Bruce Momjian wrote:
[... SIGPIPE suppression in libpq ...]
Linux also has MSG_NOSIGNAL as a send() flag that might be useful. It
suppresses generation of SIGPIPE for just that call. No, it doesn't work
for SSL and it's probably not very portable, but it might be a good
platform-specific
On K, 2004-12-01 at 18:28, Cason, Kenny wrote:
In postgres, how do I find out how many connections are allowed per
user? Where those connections are stored? Who has the connections? Etc.
You can start from:
show all;
select * from pg_stat_activity;
-
Hannu
Bruce Momjian [EMAIL PROTECTED] writes:
His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
we could also check errno for SIGPIPE rather than calling sigpending.
He has a concern about an application that already blocked SIGPIPE and
has a pending SIGPIPE signal waiting
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't currently have the resources to clean this up properly. The
attached patch tries to make clear in a comment what the code is doing,
and also initializes these variables to NULL. If someone wants to take a
stab at cleaning
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
---
*** ./expected/inherit.out Wed Dec 1 16:53:51 2004
--- ./results/inherit.out Wed Dec 1
Uh, what was the TODO here? I forgot.
---
John Hansen wrote:
I think it is *way* too late in the dev cycle to be proposing this.
Maybe it should be a TODO item - I at least don't have time even to
think about the
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in the choice of plan for that query. You seem to still be
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, what was the TODO here? I forgot.
I think we already did what we decided was safe there.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Bruce Momjian said:
Uh, what was the TODO here? I forgot.
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code. If there's a TODO it would be to investigate the possibility, as I am
very far from certain that there is a simple way to do it safely right now.
Maybe
Richard Huxton,
It feels more distinct to me. I'll grant you I'm only a sample size of
1 though.
Perhaps more distinct, but:
- Using savepoints together with try/catch is not exactly an unknown
concept. Try Google and you'll see a fair amount of examples advocating
the approach that I suggest.
On Wed, Dec 01, 2004 at 02:02:41AM -0600, Bruno Wolff III wrote:
On Mon, Nov 29, 2004 at 12:49:46 +,
Chris Green [EMAIL PROTECTED] wrote:
This is a perpetual problem, if people all used the same MUA and
(assuming it has the capability) all used the 'reply to list' command
to reply
Bruce Momjian wrote:
Comments? This seems like our only solution.
This would be a transparent solution. Another approach would be:
- Use the old 7.3 approach by default. This means perfect backward
compatibility for single-threaded apps and broken multithreaded apps.
- Add a new PQinitDB(int
Index is used incorrectly if constant part of the string ends with \d,
probably also with other escapes.
foo=# explain select count(*) from loc where url ~
'^http://www\\.7-eleven\\.com/newsroom/articles\\.asp\\?p=\\d+'; QUERY PLAN
Aggregate (cost=3.46..3.46 rows=1 width=0)
- Index Scan
On Wed, 2004-12-01 at 17:22 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in
Neil Conway [EMAIL PROTECTED] writes:
I see regression test failures in both inheritence and join (after a
fresh initdb). Attached is the regression.diffs, gzip'ed.
Yeah, so do I on a Linux machine. It looks like the dynamic size
estimates are highlighting some platform dependencies, such as
On Wed, 2004-12-01 at 11:08 -0300, Alvaro Herrera wrote:
When would the experimentation end, and 8.0 be finally released?
As I said, this is work for 8.1; I don't think it ought to affect the
release schedule of 8.0 (perhaps in some marginal way because Tom might
spend some time discussing
Neil Conway [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
I see regression test failures in both inheritence and join (after a
fresh initdb). Attached
You will be glad to know that 8.0 will use a different implementation
for thread handling of SIGPIPE, though your asynchronous handling of
SIGPIPE will still cause problems.
---
Jim Seymour wrote:
Hi,
I'm kind of
Neil Conway said:
On Wed, 2004-12-01 at 11:08 -0300, Alvaro Herrera wrote:
There's real development waiting only for release to happen ...
There is real development being done as we speak, that will be landed
to 8.1 when it branches :)
I've raised this before, but would like to suggest
Antti Salmela [EMAIL PROTECTED] writes:
Index is used incorrectly if constant part of the string ends with \d,
Yeah, you're right --- that code predates our use of the new regexp
engine, and it didn't know that escapes aren't simply quoted characters.
Now that I look at it, it's got a multibyte
Neil, where are we on this? Should we add comments? Add a TODO? A patch?
---
Neil Conway wrote:
On Wed, 2004-11-24 at 23:30 -0500, Tom Lane wrote:
It is not a 100% solution because it does not
cover the case where a
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in the choice of plan for that query. You seem to still be
getting the old plan ...
An initdb does not change the regression failure. Sorry.
Hmph. I'm unsure
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmph. I'm unsure why there's a platform dependency there, but we should
probably just add an ORDER BY to suppress it. Will do.
Why did it just appear? Optimizer changes in the past few days?
I did just change the planner, but what I
Manfred Spraul [EMAIL PROTECTED] writes:
Is that really worthwhile? There are half a dozend assumption about the
C library and kernel internal efficiency of the signal handling
functions in the proposal. Adding a PQinitLib function is obviously a
larger change, but it solves the problem.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
we could also check errno for SIGPIPE rather than calling sigpending.
He has a concern about an application that already blocked SIGPIPE and
has a pending
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in the choice of plan for that query. You seem to still be
getting the old plan ...
An initdb does not change the regression failure.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in the choice of plan for that query.
Manfred Spraul wrote:
This seems workable as long as we document the possible gotchas.
Is that really worthwhile? There are half a dozend assumption about the
C library and kernel internal efficiency of the signal handling
functions in the proposal. Adding a PQinitLib function is
Neil Conway [EMAIL PROTECTED] writes:
The attached patch invokes the transition function in the current memory
context. I don't think that's right: a memory leak in an aggregate's
transition function would be problematic when we're invoked from a
per-query memory context, as is the case with
Andrew Dunstan [EMAIL PROTECTED] writes:
I've raised this before, but would like to suggest again that there might be
virtue in branching earlier in the dev cycle - maybe around the time of the
first beta.
Given the amount of patching that's gone on, branching 8.1 earlier would
have meant a
On Wed, Dec 01, 2004 at 08:35:40PM -0500, Tom Lane wrote:
Okay, I committed some tweaks to reduce platform dependencies. I get
passes now on all three platforms I have handy.
It passes on my FreeBSD 4.10-STABLE box.
Don't know about Solaris 9/sparc yet -- the whole dance takes over
an hour
Tom Lane wrote:
If the C library does support queued signals then we will read the
existing SIGPIPE condition and leave our own signal in the queue. This
is no problem to the extent that one pending SIGPIPE looks just like
another --- does anyone know of platforms where there is additional info
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, that is the logic in my patch, except that I don't check errno, I
just call sigpending().
No, that's wrong: if there is a pending SIGPIPE that belongs to the
outer app, you'd clear it.
There are a few writes and it seemed impossible
to check them
On Wed, 2004-12-01 at 19:34 +0100, [EMAIL PROTECTED] wrote:
I regard performance testing as an essential part of the
release process of any performance critical software. Most earlier beta
releases were fixing functional problems and now the focus has moved to
performance related issues.
I
On Wed, Dec 01, 2004 at 08:10:24PM -0700, Michael Fuhr wrote:
Don't know about Solaris 9/sparc yet -- the whole dance takes over
an hour on my (t)rusty ol' Ultra 1.
Solaris 9/sparc passes all tests.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of
On 12/1/2004 1:35 PM, Brett Schwarz wrote:
--- Jan Wieck [EMAIL PROTECTED] wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Rod Taylor wrote:
Anyway, it shows a situation where it would be nice to differentiate
between statement_timeout and lock_timeout OR it demonstrates that I
should be using userlocks...
Wouldn't a LOCK NOWAIT be a better solution?
Tom Lane wrote:
Thomas F.O'Connell [EMAIL PROTECTED] writes:
So why not have VACUUM FULL FREEZE just do what you propose: VACUUM
FULL then VACUUM FREEZE.
The objective is to make it more safe, not less so. Doing that would
require rewriting a whole bunch of code, which I am not up for
On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
Neil, where are we on this? Should we add comments? Add a TODO? A patch?
I'm not sure what the right resolution is. As I said, I don't think it's
wise to apply a patch that could have a significant impact on
performance without (a)
This recent change to readline/libedit selection isn't quite right.
http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php
It doesn't link in libtermcap with libedit which leads to:
checking for readline.h... no
configure: error: readline header not found
If you have libedit
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
we could also check errno for SIGPIPE rather than calling sigpending.
He has a concern about an application that already blocked SIGPIPE and
has a pending
On Wed, 2004-12-01 at 15:54 -0500, Tom Lane wrote:
This seems like it might work. Instead of copying the result into the
aggcontext on every cycle, we could copy it only when we intend to reset
the working context.
Right.
This is
problematic since the source tuple will go away on the next
70 matches
Mail list logo
