Re: [PERFORM] Upgrading from from 7.4.2 to 8.0

2005-01-26 Thread Doug McNaught
"James Gunzelman" <[EMAIL PROTECTED]> writes: >Will I have to dump and reload all my databases when migrating from >7.4.2 to 8.0? Yes. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Anyone familiar with Apple Xserve RAID

2004-08-26 Thread Doug McNaught
Kevin Barnard <[EMAIL PROTECTED]> writes: >Actually you are both are right and wrong. The XRaid uses >FibreChannel to communicate to the host machine(s). The Raid >controller is a FibreChannel controller. After that there is a >FibreChannel to UltraATA conversion for each drive,

Re: [PERFORM] Anyone familiar with Apple Xserve RAID

2004-08-25 Thread Doug McNaught
Josh Berkus <[EMAIL PROTECTED]> writes: > Robert, > >> Just curious if folks have ever used this for a postgresql server and if >> they used it with OSX/BSD/Linux. Even if you haven't used it, if you >> know of something comparable I'd be interested. TIA > \> Last I checked Apple was still shippi

Re: [PERFORM] Slow select, insert, update

2004-08-10 Thread Doug McNaught
Paul Langard <[EMAIL PROTECTED]> writes: > Having trouble with one table (see time to count records below!). > > Fairly new to postgres so any help much appreciated. > > It only contains 9,106 records - as you can see from: > > > select count(id) from project > > count > 9106 > 1 row(s) > Total ru

Re: [PERFORM] postgres 7.4 at 100%

2004-06-26 Thread Doug McNaught
Chris Cheston <[EMAIL PROTECTED]> writes: > shared_buffers = 40 # min 16, at least max_connections*2, 8KB each This is ridiculously low for any kind of production server. Try something like 5000-1 for a start. -Doug ---(end of broadcast)

Re: [PERFORM] [BULK] Problems with vacuum!

2004-06-11 Thread Doug McNaught
"Domenico Sgarbossa" <[EMAIL PROTECTED]> writes: > Thanks for your advice! > > It seems that the cached memory isn't released by the system... so the > system begin to swap to disk! If you really think this is true, there should be a process that is holding on to the memory. Use 'ps' to find tha

Re: [PERFORM] High Performance/High Reliability File system on SuSE64

2004-01-24 Thread Doug McNaught
Paul Ganainm <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] says... > > >> XFS.. hands down. > > > Off topic question here, but I'm a bit at a loss to understand exactly > what sgi are doing. > > > I thought that they were removing IRIX and going with Linux as the OS to > their high end graphic

Re: [PERFORM] Postgresql on Quad CPU machine

2004-01-11 Thread Doug McNaught
"D. Dante Lorenso" <[EMAIL PROTECTED]> writes: > I'm running PostgreSQL 7.4 on a quad Xeon attached to a > beefy disk array. However, I am begining to wonder if this is > a waste of CPU power. > > I think I read somewhere that PostgreSQL is NOT multi-threaded. > But, will it be able to take advan

Re: [PERFORM] Select max(foo) and select count(*) optimization

2004-01-05 Thread Doug McNaught
Paul Tuckfield <[EMAIL PROTECTED]> writes: > In the case of select count(*), one optimization is to do a scan of the > primary key, not the table itself, if the table has a primary key. In a > certain commercial, lesser database, this is called an "index fast full > scan". It would be important

Re: [PERFORM] is it possible to get the optimizer to use indexes

2003-12-22 Thread Doug McNaught
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: >> It appears that the optimizer only uses indexes for = clause? > > The optimizer will used indexes for LIKE clauses, so long as the > clause is a prefix search, eg: > > SELECT * FROM test WHERE a LIKE 'prf%'; Doesn't this still depend on your