Jan Wieck <[EMAIL PROTECTED]> writes:
> On 10/8/2004 10:10 PM, Christopher Browne wrote:
>
> > [EMAIL PROTECTED] (Josh Berkus) wrote:
> >> I've been trying to peg the "sweet spot" for shared memory using
> >> OSDL's equipment. With Jan's new ARC patch, I was expecting that
> >> the desired amoun
On Thu, 2004-10-14 at 04:57, Mark Wong wrote:
> I have some DBT-3 (decision support) results using Gavin's original
> futex patch fix.
I sent an initial description of the futex patch to the mailing lists
last week, but it never appeared (from talking to Marc I believe it
exceeded the size limit
On 10/13/2004 11:52 PM, Greg Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 10/8/2004 10:10 PM, Christopher Browne wrote:
> [EMAIL PROTECTED] (Josh Berkus) wrote:
>> I've been trying to peg the "sweet spot" for shared memory using
>> OSDL's equipment. With Jan's new ARC patch, I was expecti
Jan Wieck <[EMAIL PROTECTED]> writes:
> Which would require that shared memory is not allowed to be swapped out, and
> that is allowed in Linux by default IIRC, not to completely distort the entire
> test.
Well if it's getting swapped out then it's clearly not being used effectively.
There are A
Josh Berkus wrote:
> Aaron,
>
> > That makes two of us. Hanging out with Tom, Bruce, and others at OSCON
> > 2002 was one of the most informative and fun times I've had. That and
> > I could really stand to brush up on my Postgres basics
>
> You're thinking of Jan. Tom wasn't at OSCON. ;-)
Ah
On 10/14/2004 12:22 AM, Greg Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Which would require that shared memory is not allowed to be swapped out, and
that is allowed in Linux by default IIRC, not to completely distort the entire
test.
Well if it's getting swapped out then it's clearly not be
On 10/9/2004 7:20 AM, Kevin Brown wrote:
Christopher Browne wrote:
Increasing the number of cache buffers _is_ likely to lead to some
slowdowns:
- Data that passes through the cache also passes through kernel
cache, so it's recorded twice, and read twice...
Even worse, memory that's used for th
Aaron,
> That makes two of us. Hanging out with Tom, Bruce, and others at OSCON
> 2002 was one of the most informative and fun times I've had. That and
> I could really stand to brush up on my Postgres basics
You're thinking of Jan. Tom wasn't at OSCON. ;-)
--
--Josh
Josh Berkus
Aglio Datab
On Wed, 13 Oct 2004 09:23:47 -0700, Bryan Encina
<[EMAIL PROTECTED]> wrote:
>
> Wow, that's good stuff, too bad there's no one doing stuff like that in the
> Los Angeles area.
>
> -b
That makes two of us. Hanging out with Tom, Bruce, and others at OSCON
2002 was one of the most informative and fun
Hi guys,
I have some DBT-3 (decision support) results using Gavin's original
futex patch fix. It's on out 8-way Pentium III Xeon systems
in our STP environment. Definitely see some overall throughput
performance on the tests, about 15% increase, but not change with
respect to the number of conte
> >>trainwreck... If you're going through IBM, then they won't want to
> >>respond to any issues if you're not running a
> "bog-standard" RHAS/RHES
> >>release from Red Hat.
...> To be fair, we keep on actually running into things that
> _can't_ be backported, like fibrechannel drivers that
Sent this to wrong list.
Forwarded Message
From: Robin Ericsson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [GENERAL] [PERFORM] query problem
Date: Wed, 13 Oct 2004 18:27:20 +0200
On Wed, 2004-10-13 at 18:01 +0200, Robin Ericsson wrote:
> Using exact timestamp makes th
> All,
> My company (Chariot Solutions) is sponsoring a day of free
> PostgreSQL training by Bruce Momjian (one of the core PostgreSQL
> developers). The day is split into 2 sessions (plus a Q&A session):
>
> * Mastering PostgreSQL Administration
> * PostgreSQL Performance Tuning
>
>
[EMAIL PROTECTED] (Matt Clark) writes:
>>As for "vendor support" for Opteron, that sure looks like a
>>trainwreck... If you're going through IBM, then they won't want to
>>respond to any issues if you're not running a "bog-standard" RHAS/RHES
>>release from Red Hat. And that, on Opteron, is prepo
All,
My company (Chariot Solutions) is sponsoring a day of free
PostgreSQL training by Bruce Momjian (one of the core PostgreSQL
developers). The day is split into 2 sessions (plus a Q&A session):
* Mastering PostgreSQL Administration
* PostgreSQL Performance Tuning
Registratio
On Wed, 2004-10-13 at 11:03 -0400, Tom Lane wrote:
> Robin Ericsson <[EMAIL PROTECTED]> writes:
> > I sent this to general earlier but I was redirected to performance.
>
> Actually, I think I suggested that you consult the pgsql-performance
> archives, where this type of problem has been hashed ou
Robin Ericsson <[EMAIL PROTECTED]> writes:
> I sent this to general earlier but I was redirected to performance.
Actually, I think I suggested that you consult the pgsql-performance
archives, where this type of problem has been hashed out before.
See for instance this thread:
http://archives.postg
On Wed, 2004-10-13 at 02:21, Robin Ericsson wrote:
> Hi,
>
> I sent this to general earlier but I was redirected to performance.
>
> The query have been running ok for quite some time, but after I did a
> vacuum on the database, it's very very slow.
Did you do a VACUUM FULL ANALYZE on the datab
Hi,
I sent this to general earlier but I was redirected to performance.
The query have been running ok for quite some time, but after I did a
vacuum on the database, it's very very slow. This IN-query is only 2
ids. Before the problem that in was a subselect-query returning around
6-7 ids. The ta
19 matches
Mail list logo
