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
a
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':
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 colum
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,
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 b
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 a
"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
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
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 meanti
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 issu
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 bot
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
Magnus, where are on this?
---
Magnus Hagander wrote:
> We're ok with the alignment issues provided the is code added to reject
> O_DIRECT if the sector size is too large.
>
> We also said we need to see some performance nu
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 r
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.
Heikki Linnakangas wrote:
> 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
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 d
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 thi
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
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.
regards, to
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
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 pat
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 consi
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:
> 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
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 \c
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 ser
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.
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
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.
>
Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> > I'll save the full rant for my blog :), but wanted to submit this
> > documentation
> > patch for this listen gotcha that's been bugging me for a while. I'd like
> > to see LISTEN and NOTIFY changed to use a simple text stri
Applied.
---
Marko Kreen wrote:
> Let's be decent.
>
> --
> marko
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
--
B
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 l
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 and opened in the COPY mention.
> > >
> > > >
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.
---
Si
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 tha
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
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.
---
Je
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 su
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
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 (h
"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
Let's be decent.
--
marko
pg13.diff
Description: Binary data
---(end of broadcast)---
TIP 6: explain analyze is your friend
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 and opened in the COPY mention.
> >
> > > +
> > > + static void
> > > + heap_sy
44 matches
Mail list logo