I've been working on the patch to enhance our group commit
behavior.
The patch is a dirty hack at the moment, but I'm settled on the
algorithm I'm going to use and I know the issues involved.
One question that just came to mind is whether Simon's
no-commit-wait
patch doesn't
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been working on the patch to enhance our group commit behavior. The
patch is a dirty hack at the moment, but I'm settled on the algorithm
I'm going to use and I know the issues involved.
One question that just came to mind is
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim.
Is there a reason that \da doesn't show the functions result type, like \df
does? I would find that information useful.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
I remember several cases when people (e.g. me :-) ) were spending some
time trying to find an error in some pl/pgsql function and the reason
lied in incorrect work with arrays (i.e. messages like index is out
of bounds and index cannot be negative
psql's \d command tells you about outgoing foreign key constraints
(ie, ones referencing another table from this one). It doesn't tell
you about incoming ones (ie, ones where another table references this
one). ISTM it'd be a good idea if it did, as are there any incoming
foreign keys seems to
Mark Kirkwood [EMAIL PROTECTED] writes:
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough
Hi Bruce,
How about these:
- Allow specification of TOAST size threshold in bytes on a per column basis
- Enable storage of columns in separate TOAST tables
- Enable use of multi-row compression method(s) for TOAST tables
- Luke
On 3/26/07 5:39 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Is there a reason that \da doesn't show the functions result type, like \df
does? I would find that information useful.
+1, I've been annoyed by that too.
regards, tom lane
---(end of
* Tom Lane ([EMAIL PROTECTED]) wrote:
one). ISTM it'd be a good idea if it did, as are there any incoming
foreign keys seems to be a question we constantly ask when solving
update-performance problems, and there isn't any easy way to check for
such. I'm not real sure what the printout should
On Tue, Apr 10, 2007 at 10:32:38AM -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Is there a reason that \da doesn't show the functions result type, like \df
does? I would find that information useful.
+1, I've been annoyed by that too.
Eh, but it does? As of
Am Dienstag, 10. April 2007 17:12 schrieb Magnus Hagander:
Is there a reason that \da doesn't show the functions result type, like
\df does? I would find that information useful.
Eh, but it does? As of
http://archives.postgresql.org/pgsql-committers/2007-03/msg00138.php.
Ah, OK, one
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've refrained from spending time on group commit until the
commit-no-wait patch lands, because it's going to conflict anyway. I'm
starting to feel we should not try to rush group commit into 8.3, unless
it somehow falls out of the commit-no-wait
Am Dienstag, 10. April 2007 17:30 schrieb Neil Conway:
On Tue, 2007-04-10 at 17:24 +0200, Peter Eisentraut wrote:
The new uuid type is lacking documentation.
We had also talked about including some UUID generation functionality in
8.3, but it should be okay to leave that for 8.4.
The
Peter Eisentraut wrote:
Am Dienstag, 10. April 2007 17:30 schrieb Neil Conway:
On Tue, 2007-04-10 at 17:24 +0200, Peter Eisentraut wrote:
The new uuid type is lacking documentation.
We had also talked about including some UUID generation functionality in
8.3, but it should be okay to leave
Joshua D. Drake [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance. I'm not
sure how we wanted to solve that, but certainly leaving the uuid type with
Koichi Suzuki [EMAIL PROTECTED] writes:
My proposal is to remove unnecessary full page writes (they are needed
in crash recovery from inconsistent or partial writes) when we copy WAL
to archive log and rebuilt them as a dummy when we restore from archive
log.
...
Benchmark: DBT-2
I wrote:
This patch looks fairly sane to me; I have a few small gripes about
coding style but that can be fixed while applying. Heikki, you were
concerned about the cycle-ID idea; do you have any objection to this
patch?
Actually, on second look I think the key idea here is Takahiro-san's
Kris Kennaway [EMAIL PROTECTED] writes:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim.
Correct. The
Hi Tom,
The original patch was submitted by Kai Sattler, and we (at EDB) spent a
lot of time improving it, making it as seamless and as user-friendly as
possible. As is evident from the version number of the patch (v26), it has
gone through a lot of iterations, and was available to the
(Sorry if you receive duplicate messages. I resend it since it was not
delivered after a day.)
Here is another patch to fix never-ending loop in mdsync. I introduced
a mdsync counter (cycle id) and cancel flags to fix the problem.
The mdsync counter is incremented at the every beginning of
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Here is another patch to fix never-ending loop in mdsync. I introduced
a mdsync counter (cycle id) and cancel flags to fix the problem.
The mdsync counter is incremented at the every beginning of mdsync().
Each pending entry has a field assigned from
On Tue, Apr 10, 2007 at 10:41:04PM +1200, Mark Kirkwood wrote:
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we
On Tue, Apr 10, 2007 at 10:23:42AM -0400, Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping
Hi *
I am using the postgresql-8.2.3, with a jdbc-8.2-504 (the GeoNet
webServer tool...) My question is :
Is the PostGresDB server able to log the whole SELECT query?
{made by a prepared statement}
Looking at the log I can see only queries of the type:
(cut).
LOG: execute
On 4/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
As I can see here, when I ask for element that doesn't exist, the
database returns NULL for me. Maybe it's well-known issue (and
actually I understood this behaviour before), but strictly speaking it
On 4/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
I remember several cases when people (e.g. me :-) ) were spending some
time trying to find an error in some pl/pgsql function and the reason
lied in incorrect work with arrays (i.e. messages like index
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
ISTM random() or similar
Neil Conway wrote:
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
Nikolay Samokhvalov wrote:
On 4/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
I remember several cases when people (e.g. me :-) ) were spending some
time trying to find an error in some pl/pgsql function and the reason
lied in incorrect work with
Kris Kennaway [EMAIL PROTECTED] writes:
On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
Oh, I'm sure the BSD kernel acts as you describe. But Mark's point is
that Postgres never has more than one process waiting on any particular
SysV semaphore, and so the problem doesn't really
Neil Conway wrote:
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
ISTM
On 4/10/07, Tom Lane [EMAIL PROTECTED] wrote:
ISTM it'd be a good idea if it did, as are there any incoming
foreign keys seems to be a question we constantly ask when solving
update-performance problems, and there isn't any easy way to check for
such.
Sure. We wrote a stored proc to do that
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
Kris Kennaway [EMAIL PROTECTED] writes:
I have not studied the exact code path, but there are indeed multiple
wakeups happening from the semaphore code (as many as the number of
active postgresql processes). It is easy to instrument
sleepq_broadcast() and log them when they happen.
There are
On 2007-04-10, Tom Lane [EMAIL PROTECTED] wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
I have not studied the exact code path, but there are indeed multiple
wakeups happening from the semaphore code (as many as the number of
active postgresql processes). It is easy to instrument
Kris Kennaway [EMAIL PROTECTED] writes:
On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
Anyway I'd be interested to know what the test case is, and which PG
version you were testing.
I used 8.2 (and some older version when I first noticed it a year ago)
and either sysbench or
Kris Kennaway [EMAIL PROTECTED] forwards:
Yes but there are still a lot of wakeups to be avoided in the current
System V semaphore code. More specifically, not only do we wakeup all
the processes waiting on a single semaphore everytime something changes,
but we also wakeup all processes
Maxime Henrion [EMAIL PROTECTED] writes:
Thanks for forwarding my mail, Kris! To Tom: if you can get my mails
to reach pgsql-hackers@ somehow that would be just great :-).
They'll get approved eventually, just like mine to the BSD lists will
get approved eventually ;-)
The only thing we
Tom Lane wrote:
I think the high number of setproctitle() calls are more problematic
to us at the moment, Kris can comment on that.
As of PG 8.2 it is possible to turn those off. I don't think there's a
lot of enthusiasm for turning them off by default ... at least not yet.
But it might
Hi,
In the case below, we run DBT-2 benchmark for one hour to get the
measure. Checkpoint occured three times (checkpoint interval was 20min).
For more information, when checkpoint interval is one hour, the amount
of the archived log size was as follows:
cp: 3.1GB
gzip:
In terms of idle time for gzip and other command to archive WAL offline,
no difference in the environment was given other than the command to
archive. My guess is because the user time is very large in gzip, it
has more chance for scheduler to give resource to other processes. In
the
Kris Kennaway [EMAIL PROTECTED] writes:
I think the high number of setproctitle() calls are more problematic
to us at the moment, Kris can comment on that.
Since we've basically had it handed to us that calling setproctitle()
thousands of times per second is something that real applications
# [EMAIL PROTECTED] / 2007-04-10 15:49:08 -0400:
Neil Conway wrote:
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent,
as they require MAC addresses or a good random source, for instance.
Ühel kenal päeval, T, 2007-04-10 kell 18:17, kirjutas Joshua D. Drake:
In terms of idle time for gzip and other command to archive WAL offline,
no difference in the environment was given other than the command to
archive. My guess is because the user time is very large in gzip, it
has
Hi,
On 4/11/07, Guillaume Smet [EMAIL PROTECTED] wrote:
On 4/10/07, Tom Lane [EMAIL PROTECTED] wrote:
ISTM it'd be a good idea if it did, as are there any incoming
foreign keys seems to be a question we constantly ask when solving
update-performance problems, and there isn't any easy way to
On Tue, Apr 10, 2007 at 03:52:00PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
Oh, I'm sure the BSD kernel acts as you describe. But Mark's point is
that Postgres never has more than one process waiting on any
On Tue, Apr 10, 2007 at 08:23:36PM -0400, Tom Lane wrote:
I think the high number of setproctitle() calls are more problematic
to us at the moment, Kris can comment on that.
As of PG 8.2 it is possible to turn those off. I don't think there's a
lot of enthusiasm for turning them off by
On Tue, Apr 10, 2007 at 06:26:37PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
Anyway I'd be interested to know what the test case is, and which PG
version you were testing.
I used 8.2 (and some older version
On Wed, Apr 11, 2007 at 12:50:06PM +1200, Mark Kirkwood wrote:
Tom Lane wrote:
I think the high number of setproctitle() calls are more problematic
to us at the moment, Kris can comment on that.
As of PG 8.2 it is possible to turn those off. I don't think there's a
lot of enthusiasm
On Wed, Apr 11, 2007 at 01:03:50AM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
I think the high number of setproctitle() calls are more problematic
to us at the moment, Kris can comment on that.
Since we've basically had it handed to us that calling setproctitle()
On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough
On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
I have not studied the exact code path, but there are indeed multiple
wakeups happening from the semaphore code (as many as the number of
active postgresql processes). It is easy to instrument
Kris Kennaway [EMAIL PROTECTED] writes:
On Wed, Apr 11, 2007 at 01:03:50AM -0400, Tom Lane wrote:
Well, the thing is, we've pretty much had it handed to us that
current-command indicators that aren't up to date are not very useful.
So rate-limited updates strike me as a useless compromise.
I
54 matches
Mail list logo
