On Thu, 2007-02-22 at 22:49 +, Simon Riggs wrote:
On Tue, 2007-02-20 at 14:38 -0300, Alvaro Herrera wrote:
Cool. I noticed that the SGML seems broken here:
Corrected.
You need to close the listitem and para opened in the COPY mention.
+
+ static void
+
Let's be decent.
--
marko
pg13.diff
Description: Binary data
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian [EMAIL PROTECTED] writes:
Greg, do you want to submit a patch for this or add a TODO item for this?
Well I never got any approval or rejection in principle so I don't know if
such a patch would be accepted even if it were implemented reasonably. If it
has the consensus needed to
This patch implements a circular buffer in tuplestore which drops old tuples
as they're no longer needed. It uses this for merge joins to avoid having to
spill the tuplestore if no single value exceeds work_mem. It also is what's
needed for both recursive query support and OLAP window functions
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Uh, no, that's not very clear. A long-running transaction will be a
VACUUM bottleneck because of its own XID, never mind its xmin.
Well, my secondary addition was to start MyProc-xmin with the current
xid
Jeremy Drake wrote:
On Mon, 26 Mar 2007, Bruce Momjian wrote:
Tom Lane wrote:
Or were you speaking to the question of whether to adjust the regexp
patch to conform more nearly to the coding practices found elsewhere?
I agree with that, but I thought there was already a submitted
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.
---
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own xid.
Don't tell me you seriously believe that would work.
I do. Please tell me why it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, my secondary addition was to start MyProc-xmin with the current
xid counter, rather than your own xid.
Don't tell me you seriously believe that would work.
I do.
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.
---
Simon Riggs wrote:
On Thu, 2007-02-22 at 22:49 +, Simon Riggs wrote:
On Tue, 2007-02-20 at 14:38 -0300, Alvaro Herrera wrote:
Cool. I noticed that the SGML seems broken here:
Corrected.
You need to close the listitem and para opened in the COPY mention.
+
+
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Currently PgPool solves the situation by parsing all queries
and keeping
Applied.
---
Marko Kreen wrote:
Let's be decent.
--
marko
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Bruce
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As
On Tue, 2007-03-27 at 10:28 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2007-02-22 at 22:49 +, Simon Riggs wrote:
Could we add this to the unapplied patches queue? It seems to have been
missed off the list. Thanks.
Done.
Many thanks
--
Simon Riggs
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
What is the status of this patch?
---
FAST PostgreSQL wrote:
Hi,
I've been working on the following TODO item and attached is an initial
patch. (It is only partial and not yet completely functional)
Allow server
This is just an update against CVS.
The interface is still as described at this URL:
http://community.enterprisedb.com/concurrent/index.html
It's true there isn't any documentation in the patch but I'm not sure we're
actually settled on the interface.
I think our experience here is that the
Heikki Linnakangas [EMAIL PROTECTED] writes:
But what surprises me is that response times went up a with the patch. I
don't know why.
Maybe because of increased contention of ProcArrayLock? (I assume you
are using that, althought I haven't seen the patch)
I am, but I doubt that's it. The
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, at least for now. I can't believe the patch actually hurts performance,
but I'm not going to spend time investigating it.
Isn't this exactly what you would expect? It will clean up more tuples so
it'll dirty more pages.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
So are you stopping work on the patch? I assume so.
Yes, at least for now. I can't believe the patch actually hurts
performance, but I'm not going to spend time investigating it.
Are we withdrawing the patch from
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
So are you stopping work on the patch? I assume so.
Yes, at least for now. I can't believe the patch actually hurts
performance, but I'm not going to spend time investigating it.
Are we withdrawing the
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
So are you stopping work on the patch? I assume so.
Yes, at least for now. I can't believe the patch actually hurts
performance, but I'm not going to spend time investigating
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we should keep this issue open until we resolve the vacuum WAL
flush issue? I can then rerun the same tests to see if this patch is a
win after that.
Sounds like a plan, if you are willing to do that.
Sure, just rerunning
I have remove this TODO item:
* %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
These would be for application use, not for use by pg_dump.
Seems there is lack of interest in adding
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Huh, didn't we have a RESET SESSION command to do
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Huh,
Gregory Stark wrote:
The main design issue is that I was proposing to make it impossible to access
the internals of the numeric storage using macros. Currently some of the data
(the sign, dscale, and weight) is visible without having to call any special
numeric functions. I was proposing to use
On 3/27/07, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new
The following table add's a new variant of the CLUSTER command. The old
variants are preserved, as suggested in the TODO entry.
Things I changed:
* The grammar
* psql help text
* psql tab-completion, it favours now CLUSTER table ORDER BY index
* two uses of CLUSTER in the regression, so that
IIRC, we're still waiting for performance numbers showing there exists a
win from this patch.
//Magnus
Bruce Momjian wrote:
Magnus, where are on this?
---
Magnus Hagander wrote:
We're ok with the alignment issues
Hi,
This is the first non-trivial patch to autovacuum multiple workers.
This patch that adds the recheck logic to autovacuum worker. With
this, the worker first builds its table list and then rechecks pgstat
before vacuuming each table to verify that no one has vacuumed the table
in the
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
and
http://archives.postgresql.org/pgsql-patches/2007-01/msg00607.php
Update includes some
Holger Schurig [EMAIL PROTECTED] writes:
* psql tab-completion, it favours now CLUSTER table ORDER BY index
It occurs to me (sorry that I didn't think of this earlier) that if we're
going to use ORDER BY it really ought to take a list columns. It would be
more consistent with what ORDER BY
Hi,
This is the patch to put multiple workers into autovacuum. This patch
applies after the recheck patch I just posted.
The main change is to have an array of Worker structs in shared memory;
each worker checks the current table of all other Workers, and skips a
table that's being vacuumed by
On Tue, 2007-03-27 at 13:32 +0100, stark wrote:
This patch implements a circular buffer in tuplestore which drops old tuples
as they're no longer needed. It uses this for merge joins to avoid having to
spill the tuplestore if no single value exceeds work_mem. It also is what's
needed for both
On Tue, 2007-03-27 at 17:41 -0400, Alvaro Herrera wrote:
The main change is to have an array of Worker structs in shared memory;
each worker checks the current table of all other Workers, and skips a
table that's being vacuumed by any of them. It also rechecks the table
before vacuuming,
Gregory Stark [EMAIL PROTECTED] writes:
Holger Schurig [EMAIL PROTECTED] writes:
* psql tab-completion, it favours now CLUSTER table ORDER BY index
It occurs to me (sorry that I didn't think of this earlier) that if we're
going to use ORDER BY it really ought to take a list columns.
Surely
Here are two small code clean-up in initdb and win32_shmem.
pg_char_to_encoding() was redundant in initdb because
pg_valid_server_encoding() returns the same result if the encoding is valid,
Changes in win32_shmem suppress the following warnings.
| pg_shmem.c: In function `PGSharedMemoryCreate':
Simon;
Thanks a lot for your comments/advices. I'd like to write some feedback.
Simon Riggs wrote:
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/msg01491.php
40 matches
Mail list logo
