Worky,
On 10/27/06 8:47 PM, "Worky Workerson" <[EMAIL PROTECTED]> wrote:
1 0 345732 29304 770272 12946764 0 0 16 16428 1192 3105 12 2 85 1
1 0 345732 30840 770060 12945480 0 0 20 16456 1196 3151 12 2 84 1
1 0 345732 32760 769972 12943528 0 0 12 16460 1185 3103 11 2 86 1
On 10/27/06, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > r b swpd free buffcache si so bibo in cs us sy id wa
> > 1 0 345732 29328 770980 12947212 0 0 20 16552 1223 3677 12 2 85 1
> > 1 0 345732 29840 770520 12946924 0 0 20 29244 1283 2955 11 2 85 1
> > 1 0 345732 32144
Worky (that your real name? :-)
Nope, its Mike. worky.workerson is just the email that I use for "work" :)
How many CPUs on the machine? Can you send the result of "cat
/proc/cpuinfo"?
Not at work at the moment, however I do have quad dual-core opterons,
like Merlin mentioned.
Is your "c
On 10/28/06, Luke Lonergan <[EMAIL PROTECTED]> wrote:
Worky (that your real name? :-)
On 10/27/06 12:08 PM, "Worky Workerson" <[EMAIL PROTECTED]> wrote:
> Here it is, taken from a spot about halfway through a 'cat file |
> psql' load, with the "Oracle-is-installed-and-running" caveat:
>
> r b
Worky (that your real name? :-)
On 10/27/06 12:08 PM, "Worky Workerson" <[EMAIL PROTECTED]> wrote:
> Here it is, taken from a spot about halfway through a 'cat file |
> psql' load, with the "Oracle-is-installed-and-running" caveat:
>
> r b swpd free buffcache si so bibo in cs u
On Fri, 27 Oct 2006 14:07:43 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> So the time is all in index vacuuming, eh? I think what's happening
> is that the physical order of the index is degrading over time, and
> so the vacuum scan takes longer due to more seeking. Can you afford
> to do a REIND
The read speed on your /data volume is awful to the point where you should
consider it broken and find a fix. A quick comparison: the same number on a
16 drive internal SATA array with 7200 RPM disks gets 950 MB/s read, about
25 times faster for about 1/4 the price.
I'm hoping that the poor per
On 10/27/06, Worky Workerson <[EMAIL PROTECTED]> wrote:
I'm hoping that the corporate Oracle machine won't shut down my pg
projects. On total side note, if anyone knows how to best limit
Oracle's impact on a system (i.e. memory usage, etc), I'd be
interested.
rm -rf /usr/local/oracle?
merlin
I do have a dirty little secret, one which I wasn't completely aware
of until a little while ago. Apparently, someone decided to install
Oracle on the server, and use the SAN as the primary tablespace, so
that might have something to do with the poor performance of the SAN.
At least, I'm hoping t
Gavin Hamill <[EMAIL PROTECTED]> writes:
> 2006-10-27 08:37:12 UTC INFO: vacuuming "public.Allocation"
> 2006-10-27 08:37:21 UTC INFO: "Allocation": found 56449 removable, 4989360
> nonremovable row versions in 47158 pages
> 2006-10-27 08:37:21 UTC DETAIL: 0 dead row versions cannot be removed
On Sat, 2005-02-05 at 11:25, Dirk Lutzebaeck wrote:
> Hi,
>
> here is a query which produces over 1G temp file in pgsql_tmp. This
> is on pgsql 7.4.2, RHEL 3.0, XEON MP machine with 32GB RAM, 300MB
> sort_mem and 320MB shared_mem.
First step, upgrade to the latest 7.4.x version. 7.4.2 is an OLD
He is probably using IPOT (IP Other Time) : http://kadreg.free.fr/ipot/ :-) (sorry only french page ) On Oct 27, 2006, at 16:33, Bricklen Anderson wrote:Merlin Moncure wrote: On 2/5/05, Dirk Lutzebaeck <[EMAIL PROTECTED]> wrote: Was the original message actually from 2/5/05?---
Hi,
I'm sorry but it look like my computer has resent older posts from me,
sigh...
Dirk
Alexander Staubo wrote:
While I can't explain why PostgreSQL would use that
memory, I recommend looking into tweaking the work_mem parameter. This
setting specifies how much memory PostgreSQL on certain
While I can't explain why PostgreSQL would use that memory, I
recommend looking into tweaking the work_mem parameter. This setting
specifies how much memory PostgreSQL on certain temporary data
structures (hash tables, sort vectors) until it starts using
temporary files. Quoting the docs:
Merlin Moncure wrote:
On 2/5/05, Dirk Lutzebaeck <[EMAIL PROTECTED]> wrote:
Was the original message actually from 2/5/05?
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comman
On 2/5/05, Dirk Lutzebaeck <[EMAIL PROTECTED]> wrote:
here is a query which produces over 1G temp file in pgsql_tmp. This
is on pgsql 7.4.2, RHEL 3.0, XEON MP machine with 32GB RAM, 300MB
sort_mem and 320MB shared_mem.
Below is the query and results for EXPLAIN and EXPLAIN ANALYZE. All
tables ha
Thanks a lot for your help.
Thanks,
Soni
On 10/17/06, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
On 10/17/06, soni de <
[EMAIL PROTECTED]> wrote:
I didn't understand the "Bitmap Scan" and the sentence "indexes will be dynamically converted to bitmaps in memory". What does mean by "Bitmap Sc
Hello,
My Server is crashed in PQfinish. Below is the core file details:
=>[1] DLRemHead(0x2b7780, 0xfb6bc008, 0x319670, 0xfb6bc008, 0x21c40, 0x3106f8), at 0xfded10e4 [2] DLFreeList(0x2b7780, 0x0, 0x417b48, 0xfdec5aa4, 0x21c18, 0x0), at 0xfded0c64 [3] freePGconn(0x371ea0, 0x0, 0x289f48, 0xfbf
Hi,
here is a query which produces over 1G temp file in pgsql_tmp. This
is on pgsql 7.4.2, RHEL 3.0, XEON MP machine with 32GB RAM, 300MB
sort_mem and 320MB shared_mem.
Below is the query and results for EXPLAIN and EXPLAIN ANALYZE. All
tables have been analyzed before.
Can some please explain
On Thu, 26 Oct 2006 18:09:37 -0400
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 26, 2006 at 09:35:56PM +0100, Gavin Hamill wrote:
> >
> > I'm absolutely certain. The backups run from only one slave, given
> > that it is a full copy of node 1. Our overnight traffic has not
> > increase
20 matches
Mail list logo
