> This indeeds performs good (about 1 times faster then select number,url
> from mm_mediasources order by number desc limit 20) . But hardly beautiful,
> and quite useless too because of course I am now going to want to use an
> offset (limit 20 offset 20, you see..), which seems more or less
On Thu, 2004-04-22 at 07:02, Michiel Meeuwissen wrote:
> Rod Taylor <[EMAIL PROTECTED]> wrote:
> > The scan is picking the best method for grabbing everything within the
> > table, since it is not aware that we do not require everything.
>
> Hmm. That is a bit silly. Why does it use the index if s
Ron Mayer <[EMAIL PROTECTED]> writes:
> [ on setting shared_buffers = half of RAM ]
> One minor detail... You wouldn't really cache the _exact_ same blocks
> because cache-hits in shared-buffers (on the most frequently accessed
> pages) would let the OS cache some other pages in it's cache.
> Bu
"Chris Hoover" <[EMAIL PROTECTED]> writes:
> Here is the postgresql.conf from the server with the 11GB db:
> max_fsm_pages = 1 # min 1000, fsm is free space map, ~6 bytes
It's unlikely that that's enough for an 11Gb database, especially if
you're only vacuuming a few times a week. Yo
On Fri, 23 Apr 2004, Manfred Koizar wrote:
>
> Setting shared_buffers to half your available memory is the worst thing
> you can do. You would end up caching exactly the same set of blocks in
> the internal buffers and in the OS cache, thus effectively making one of
> the caches useless.
One min
On Fri, 23 Apr 2004 10:20:10 -0400, Pallav Kalva <[EMAIL PROTECTED]> wrote:
> the database sizes is around 2- 4 gig and
>there are 5 of them. this machine is
> mainly for the databases and nothing is running on them.
Did I understand correctly that you run (or plan to run) five
postmasters?
Chris Hoover wrote:
On Friday 23 April 2004 14:57, Ron St-Pierre wrote:
Does this apply to 7.3.4 also?
No it doesn't, I didn't look back through the thread far enough to see
what you were running. I tried it on 7.3.4 and none of the summary info
listed below was returned. FWIW one of our DBs wa
On Fri, 23 Apr 2004, Chris Hoover wrote:
> On Friday 23 April 2004 13:21, scott.marlowe wrote:
> > On Fri, 23 Apr 2004, Chris Hoover wrote:
> > > DB's on Powervaults 220S using raid 5 (over 6 disks)
> >
> > What controller is this, the adaptec? We've found it to be slower than
> > the LSI megarai
On Friday 23 April 2004 14:57, Ron St-Pierre wrote:
Does this apply to 7.3.4 also?
> Actually, since he's running 7.4, there's an even better way. Do a
> "VACUUM VERBOSE" (full-database vacuum --- doesn't matter whether you
> ANALYZE or not). At the end of the very voluminous output, you'll se
Josh Berkus wrote:
Chris,
Sorry for the confusion here. I can't run any sort of vacuum durin the day
due to performance hits. However, I have run vacuums at night. Several
nights a week I run a vacuumdb -f -z on all of the clusters. I can take
serveral hours to complete, but it does compl
Guys,
> Well, inserts create some locks - perhaps that's the problem...
>
> Otherwise, check the pg_locks view to see if you can figure it out.
FWIW, I've had this happen a couple of times, too. Unfortunately, it's
happend in the middle of the day so that I had to cancel the processes and
get
Chris,
> Sorry for the confusion here. I can't run any sort of vacuum durin the day
> due to performance hits. However, I have run vacuums at night. Several
> nights a week I run a vacuumdb -f -z on all of the clusters. I can take
> serveral hours to complete, but it does complete.
Well, her
PWFPM_DEV=# select * from pg_locks;
relation | database | transaction | pid | mode |
granted
--+--+-+---+--+-
17472 |17347 | | 2618 | ShareUpdateExclusiveLock | t
| |
On Friday 23 April 2004 13:21, scott.marlowe wrote:
> On Fri, 23 Apr 2004, Chris Hoover wrote:
> > DB's on Powervaults 220S using raid 5 (over 6 disks)
>
> What controller is this, the adaptec? We've found it to be slower than
> the LSI megaraid based controller, but YMMV.
>
We are using the perc3
Sorry for the confusion here. I can't run any sort of vacuum durin the day
due to performance hits. However, I have run vacuums at night. Several
nights a week I run a vacuumdb -f -z on all of the clusters. I can take
serveral hours to complete, but it does complete.
During the day, I have
I know the numbers look ok, but we are definetly suffering. Also, if I try to
run any sort of vacuum or other db activity during normal business hours,
load goes through the roof. I have seen loads of over 10 when trying to
vacuum the larger cluster and would have to kill the vacuums due to
c
On Fri, 23 Apr 2004, Chris Hoover wrote:
> DB's on Powervaults 220S using raid 5 (over 6 disks)
What controller is this, the adaptec? We've found it to be slower than
the LSI megaraid based controller, but YMMV.
> Running RH ES 2.1
Are you running the latest kernel for ES 2.1? Early 2.4 kern
Chris,
> I need some help. I have 5 db servers running our database servers, and
> they all are having various degrees of performance problems. The problems
> we are experiencing are:
I'mm confused. You're saying "general slowness" but say that most queries run
in under .01 seconds. And you
On Thu, 22 Apr 2004, Sean Shanny wrote:
> I should have included this as well:
> fsync | on
> shared_buffers | 4000
> sort_mem | 64000
For purposes of loading only, you can try turning off fsync, assuming this
is a virgin load an
Your second server has queuing (load averages are highish), only 2 processes
running, and almost all cycles are idle. You need to track down your
bottleneck. Have you looked at iostat/vmstat? I think it would be useful to
post these, ideally both before and after full vacuum analyze.
/Aaron
I need some help. I have 5 db servers running our database servers, and they
all are having various degrees of performance problems. The problems we are
experiencing are:
1. General slowness
2. High loads
All of our db's are running on Dell Poweredge 2650 with 2 P4 Xeons (2.8 ->
3.06 GHz)
By definition, it is equivalent to:
SELECT t1.id, t2.url FROM referral_temp t2 LEFT /*OUTER*/ JOIN d_referral t1
ON t2.url = t1.referral_raw_url
union all
SELECT null, url FROM referral_temp WHERE url is null
ORDER BY 1;
/Aaron
- Original Message -
From: "Joe Conway" <[EMAIL PROTECTED
22 matches
Mail list logo
