Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Jeff
On Thu, 30 Oct 2003 17:49:08 -0200 (BRST) "alexandre :: aldeia digital" <[EMAIL PROTECTED]> wrote: > Both use: Only postgresql on server. Buffers = 8192, effective cache = > 10 > Well, I'm assuming you meant 1GB of ram, not 1MB :) Check a ps auxw to see what is running. Perhaps X is runnin

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Shridhar Daithankar
Jeff wrote: On Thu, 30 Oct 2003 17:49:08 -0200 (BRST) "alexandre :: aldeia digital" <[EMAIL PROTECTED]> wrote: Both use: Only postgresql on server. Buffers = 8192, effective cache = 10 Well, I'm assuming you meant 1GB of ram, not 1MB :) Check a ps auxw to see what is running. Perhaps X is ru

Re: [PERFORM] redundent index?

2003-10-31 Thread Manfred Koizar
On Wed, 29 Oct 2003 10:17:24 -0500, Rod Taylor <[EMAIL PROTECTED]> wrote: >On Wed, 2003-10-29 at 09:03, Robert Treat wrote: >> Indexes: entity_watch_map_pkey primary key btree (entity_id, watch_id), >> ewm_entity_id btree (entity_id), >> >> I can't think of why the second index is there,

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread alexandre :: aldeia digital
Scott, Jeff and Shridhar: 1 GB RAM :) The stock kernels are not the same, HyperThreading enabled. 80 simultaneous connections. sort_mem = 4096 I will compile my own kernel on this weekend, and I will report to the list after. Thank's all Alexandre > Also are two kernels exactly same? In my e

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Andrew Sullivan
On Fri, Oct 31, 2003 at 12:03:59PM -0200, alexandre :: aldeia digital wrote: > Scott, Jeff and Shridhar: > > 1 GB RAM :) > > The stock kernels are not the same, HyperThreading enabled. 80 Some people have reported that things actually slow down with HT enabled. Have you tried turning it off? A

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Rob Sell
Not being one to hijack threads, but I haven't heard of this performance hit when using HT, I have what should all rights be a pretty fast server, dual 2.4 Xeons with HT 205gb raid 5 array, 1 gig of memory. And it is only 50% as fast as my old server which was a dual AMD MP 1400's with a 45gb raid

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Jeff
On Fri, 31 Oct 2003 09:31:19 -0600 "Rob Sell" <[EMAIL PROTECTED]> wrote: > Not being one to hijack threads, but I haven't heard of this > performance hit when using HT, I have what should all rights be a > pretty fast server, dual 2.4 Xeons with HT 205gb raid 5 array, 1 gig > of memory. And it is

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Shridhar Daithankar
Jeff wrote: On Fri, 31 Oct 2003 09:31:19 -0600 "Rob Sell" <[EMAIL PROTECTED]> wrote: Not being one to hijack threads, but I haven't heard of this performance hit when using HT, I have what should all rights be a pretty fast server, dual 2.4 Xeons with HT 205gb raid 5 array, 1 gig of memory. And i

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Bill Moran
Just for an additional viewpoint. I'm finishing up a project based on FreeBSD and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested the application with hyperthreading enabled and disabled. To all appearances, enabling hyperthreading makes the box act like a quad, with t

[PERFORM] index creation order?

2003-10-31 Thread Allen Landsidel
Yet another question.. thanks to everyone responding to all these so far.. ;) This one is basically.. given I have a big table already in COPY format, about 28 million rows, all keys guaranteed to be unique, I'm trying to find out which of the following will get the import finished the fastest:

Re: [PERFORM] index creation order?

2003-10-31 Thread Rod Taylor
If it is 7.4 beta 5 or later, I would definitely go with A. Adding indexes after the fact seems to be much quicker. Foreign keys use the same algorithm prior to beta 5 regardless of timing. A primary key and unique index will have approx the same performance (a check for NULL isn't very costly).

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Greg Stark
Bill Moran <[EMAIL PROTECTED]> writes: > Just for an additional viewpoint. I'm finishing up a project based on FreeBSD > and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested > the application with hyperthreading enabled and disabled. To all appearances, > enabling hype

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Rob Sell
For the record I am running on SuSE with a pretty much stock kernel. Not to sound naïve, but is turning of HT something done in the bios? Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Moran Sent: Friday, October 31, 2003 9:56 AM To: [EMAIL PROT

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Bill Moran
Greg Stark wrote: Bill Moran <[EMAIL PROTECTED]> writes: Just for an additional viewpoint. I'm finishing up a project based on FreeBSD and PostgreSQL. The target server is a Dual 2.4G Intel machine. I have tested the application with hyperthreading enabled and disabled. To all appearances, ena

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Andrew Sullivan
On Fri, Oct 31, 2003 at 10:42:06AM -0600, Rob Sell wrote: > For the record I am running on SuSE with a pretty much stock kernel. Not to > sound na?ve, but is turning of HT something done in the bios? As far as I know, yes. A -- Andrew Sullivan 204-4141 Yonge Street

Re: [PERFORM] index creation order?

2003-10-31 Thread Josh Berkus
Allen, > a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then > CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and > each fk needed. Did you ANALYZE after the copy? > If there isn't a significant difference between all of them, performance > wise, I

Re: [PERFORM] index creation order?

2003-10-31 Thread Allen Landsidel
At 12:10 10/31/2003, Josh Berkus wrote: Allen, > a) CREATE TABLE with no indexes or keys. Run the COPY (fast, ~30min), then > CREATE INDEX on each column it's needed on, and ALTER TABLE for the pk and > each fk needed. Did you ANALYZE after the copy? No, and this was my major mistake. I normally

Re: [PERFORM] index creation order?

2003-10-31 Thread Allen Landsidel
Nope, still 7.3.4 here.. I am very excited about 7.4 though.. almost as excited as I am about FreeBSD 5.x going -STABLE.. it's a close race between the two.. I'll keep this in mind for when I update though, thanks. At 11:23 10/31/2003, Rod Taylor wrote: If it is 7.4 beta 5 or later, I would de

Re: [PERFORM] index creation order?

2003-10-31 Thread Neil Conway
On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote: > I had no idea analyze was playing such a big role in this sense.. I really > thought that other than saving space, it wasn't doing much for tables that > don't have indexes on the. ANALYZE doesn't save any space at all -- VACUUM is probably w

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread Neil Conway
On Fri, 2003-10-31 at 11:37, Greg Stark wrote: > My understanding is that the case where HT hurts is precisely your case. When > you have two real processors with HT the kernel will sometimes schedule two > jobs on the two virtual processors on the same real processor leaving the two > virtual proc

Re: [PERFORM] index creation order?

2003-10-31 Thread Josh Berkus
Allen, > I had no idea analyze was playing such a big role in this sense.. I really > thought that other than saving space, it wasn't doing much for tables that > don't have indexes on the. Among other things, ANALYZE tells postgres how many rows are in the table. So if you add a PK constraint

Re: [PERFORM] index creation order?

2003-10-31 Thread Allen Landsidel
At 13:40 10/31/2003, Neil Conway wrote: On Fri, 2003-10-31 at 13:27, Allen Landsidel wrote: > I had no idea analyze was playing such a big role in this sense.. I really > thought that other than saving space, it wasn't doing much for tables that > don't have indexes on the. ANALYZE doesn't save any

Re: [PERFORM] Pg+Linux swap use

2003-10-31 Thread scott.marlowe
We had a problem at work that when a windows box would connect to a samba share with a lot of files in it, the kswapd was going nuts, even though we weren't low on memory at all. Updating to the 2.4.18 or so of the later redhats fixed that issue. It might be related. I think the kflush daemon

Re: [PERFORM] index creation order?

2003-10-31 Thread Chester Kustarz
is there any way to update the stats inside a transaction? what i have is something like: select count(*) from foo; -> 0 begin; copy foo from '/tmp/foo'; -- about 100k rows -- run some queries on foo which perform horribly because the stats -- are way off (100k rows v. 0 rows) commit; it see

[PERFORM] Postgres 7.3.4 + Slackware 9.1

2003-10-31 Thread PostgreSQL
Hello all! Do anyone have experience installing Postgres 7.3.4 on Slackware 9.1? Do exist any trouble, bug, problem... or is a good MIX? I want to "leave" RedHat (9) because is not "free" anymore and i don't want to use fedora BETA TEST versions. Any suggestion? THANKS ALL. --

Re: [PERFORM] index creation order?

2003-10-31 Thread Rod Taylor
> begin; > analyze foo; > ERROR: ANALYZE cannot run inside a BEGIN/END block > > i am using version 7.2.3. Time to upgrade. 7.3 / 7.4 allows this to happen. signature.asc Description: This is a digitally signed message part

Re: [PERFORM] Postgres 7.3.4 + Slackware 9.1

2003-10-31 Thread Evil Azrael
Hi! I haven´t really tested it on Slackware 9.1. But i am running Postgresql now for over two years on various Slackware versions. My current server is running on Slackware 8.0 with a lot of packages (especially the core libs) upgraded to slack 9.1 packages. I had never problems with postgresql r

Re: [PERFORM] index creation order?

2003-10-31 Thread Tom Lane
Chester Kustarz <[EMAIL PROTECTED]> writes: > it seems that you cannot run analyze inside a transaction: You can in 7.3.* ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unreg

[ PROBLEM SOLVED ] Re: [PERFORM] Query puts 7.3.4 on endless loop but 7.4beta5 is fine.

2003-10-31 Thread Rajesh Kumar Mallah
Well Sorry everyone , The problem was tracked down to a silly datatype mismatch between two join columns in table Groups(instance) and Tickets(id) (int vs varchar ) 7.4b5 is automatically taking care of this mismatch hence it was getting executed there. But , The problem is will this behaviour

Re: [linux-lvm] RE: [ADMIN] [PERFORM] backup/restore - another ar ea.

2003-10-31 Thread Nathan Scott
On Thu, Oct 30, 2003 at 10:28:10AM -0700, [EMAIL PROTECTED] wrote: > Does xfs_freeze work on red hat 7.3? It works on any kernel with XFS (it talks directly to XFS). cheers. -- Nathan ---(end of broadcast)--- TIP 2: you can get off all lists at o