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
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
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 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
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
[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
>
>
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
> >>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
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
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
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 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
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
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
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
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
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
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
19 matches
Mail list logo