"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Just experienced a server that was spending over 50% of CPU time in the
> system, apparently dealing with postmasters that were in the sblock
> state. Looking at the FreeBSD source, this indicates that the process is
> waiting for a lock on a socket. Dur
On Tue, May 02, 2006 at 12:00:42PM -0500, Jim C. Nasby wrote:
> On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
> > On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
> > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > > I think a big point that's being missed here is that SERIAL *
Just experienced a server that was spending over 50% of CPU time in the
system, apparently dealing with postmasters that were in the sblock
state. Looking at the FreeBSD source, this indicates that the process is
waiting for a lock on a socket. During this time the machine was doing
nearly 200k con
Back in the discussion of this someone had mentioned capturing all the
info that you'd get from a vacuum verbose; dead tuples, etc. What do
people think about that? In particular I think it'd be handy to know how
many pages vacuum wanted in the FSM vs. how many it got; this would make
it much easie
On Tue, May 02, 2006 at 04:31:14PM +0200, letizia leo wrote:
>
> and the doubt is the following: how is it possible that -line 144- Xmin
> is the current transaction ( i.e. it has created this tuple, it is
> holding an exclusive lock on it since it has not committed yet) and
> that
> -line 1
letizia leo wrote:
> and the doubt is the following: how is it possible that -line 144- Xmin
> is the current transaction ( i.e. it has created this tuple, it is
> holding an exclusive lock on it since it has not committed yet) and
> that
> -line 149- there is a different (?) transaction that
Hi, We're a team from Rome University (Italy) and we are working on an hacking of PostgreSQL MVCC. The basic idea is to have multiple instances of a same user transaction concurrently executing against the DB in order to achieve fault tolerance. We do not want to bother you with the details o
Looks good to me. Short and sweet.
On Tue, May 02, 2006 at 01:18:03PM -0500, Larry Rosenman wrote:
> Greetings,
> I've got a patch to be reviewed for having the stats system keep
> track of the last
> time a table was vacuumed or analyzed either by the user or via
> AutoVacuum.
>
> The patch
Just noticed a typo in newly added ginxlog.c. I don't have line
numbers, but in ginRedoSplit() it reads:
PageSetLSN(rpage, lsn);
PageSetTLI(lpage, ThisTimeLineID);
MarkBufferDirty(rbuffer);
PageSetLSN(lpage, lsn);
PageSetTLI(lpage, ThisTimeLineID);
Larry Rosenman wrote:
> Greetings,
> I've got a patch to be reviewed for having the stats system keep
> track of the last
> time a table was vacuumed or analyzed either by the user or via
> AutoVacuum.
>
> The patch is at:
> http://www.lerctr.org/~ler/pg-dev/vacuum-autovacuum-times-stats.diff
Greetings,
I've got a patch to be reviewed for having the stats system keep
track of the last
time a table was vacuumed or analyzed either by the user or via
AutoVacuum.
The patch is at:
http://www.lerctr.org/~ler/pg-dev/vacuum-autovacuum-times-stats.diff
I'd appreciate a full review, it incl
On Tue, May 02, 2006 at 05:00:58PM +0200, Zeugswetter Andreas DCP SD wrote:
>
> > I'm planning on continuing to increase XLOG_BLCKSZ and wal_buffers to
> > determine when the throughput starts to level out or drop
>
> I think for an even better comparison you should scale wal_buffers
> down with
On Mon, May 01, 2006 at 06:43:00PM -0700, elein wrote:
> On Mon, May 01, 2006 at 07:47:06PM -0400, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > I think a big point that's being missed here is that SERIAL *is* trying
> > > to be simple. If you need something more sophisticate
On Mon, May 01, 2006 at 10:24:50PM +0200, Dawid Kuroczko wrote:
> VACUUM table WHERE some_col > now()-'1 hour'::interval;
>
> I.e. Let vacuum run "piggyback" on some index. This would allow
> for a quick vacuum of a fraction of a large table. Especially when
> the table is large, and only some d
> I'm planning on continuing to increase XLOG_BLCKSZ and wal_buffers to
> determine when the throughput starts to level out or drop
I think for an even better comparison you should scale wal_buffers
down with increasing XLOG_BLCKSZ, so that the xlog buffer has a fixed
size in kb.
Reasonable wal
Simon Riggs wrote:
> On Fri, 2006-04-28 at 22:38 +0200, Martijn van Oosterhout wrote:
>> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
Martijn van Oosterhout writes:
> You know, rather than adding new columns to pg_class, why not
> extend the stats collector to colle
On 5/2/06, Mark Cave-Ayland <[EMAIL PROTECTED]> wrote:
That's great news. While I wouldn't say that I have intimate knowledge of
the PostgreSQL internals, I'd be happy to try and help you with this if time
is proving to be a problem.
Time is certainly an issue. After I post the patches, your a
Ühel kenal päeval, T, 2006-05-02 kell 00:27, kirjutas Brandon Black:
> On 4/30/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> > On Fri, 28 Apr 2006, Brandon Black wrote:
> >
> > > I dug around in CVS to have a look for this, and I did eventually find
> > > it (well, I found the corresponding d
On 5/2/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Tue, 2006-05-02 at 00:27 -0500, Brandon Black wrote:
> I tried things like the above with small test data sets against cvs
> just now on my home machine, and constraint exclusion doesn't seem to
> apply here (even if all of the joined jstuff r
On Fri, 2006-04-28 at 22:38 +0200, Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > > Martijn van Oosterhout writes:
> > >> You know, rather than adding new columns to pg_class, why not extend
> > >> the stats collector to collect this information
You need to submit this through Google.
Student FAQ:
http://code.google.com/soc/studentfaq.html
Student Sign-up:
http://code.google.com/soc/student_step1.html
On 5/2/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
Proposal: XMLType for PostgreSQL.
*** Minimum: ***
to have special type supp
On Fri, 2006-04-28 at 15:58 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > So for you it would certainly help a lot to be able to vacuum the first
> > > X pages of the big table, stop, release locks, create new transaction,
> > > continue with the
On Tue, 2006-05-02 at 00:27 -0500, Brandon Black wrote:
> I tried things like the above with small test data sets against cvs
> just now on my home machine, and constraint exclusion doesn't seem to
> apply here (even if all of the joined jstuff rows have ids which only
> match the constraint for b
On Sun, 2006-04-30 at 22:14 -0700, Mark Wong wrote:
> I would have gotten this out sooner but I'm having trouble with our
> infrastructure. Here's a link to a table of data I've started putting
> together regarding XLOG_BLCKSZ and wal_buffers on a 4-way Opteron
> system:
> http://developer.o
> -Original Message-
> From: Jonah H. Harris [mailto:[EMAIL PROTECTED]
> Sent: 01 May 2006 14:56
> To: Mark Cave-Ayland
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] WITH/WITH RECURSIVE implementation discussion
>
> On 5/1/06, Mark Cave-Ayland <[EMAIL PROTECTED]> wrote:
> > T
Proposal: XMLType for PostgreSQL.
*** Minimum: ***
to have special type support for storing XML data and working with it.
This means following:
- ability to define any column of a table as of XMLType; internally,
all data is stored as VARCHAR;
- auto validation of documents against XML schema, if
26 matches
Mail list logo
