Re: [PERFORM] Postgres 8 vs Postgres 7.4/cygwin

Scott Goldstein [EMAIL PROTECTED] writes: I'm currently trying to make a decision on whether to use the Cygwin port of Postgres 7.4 or Postgres 8.0 for a windows installation. Can someone provide some comparison info from a performance point of view? I was thinking that the Cygwin port

[PERFORM] Speed with offset clause

Hi again all, My queries are now optimised. They all use the indexes like they should. However, there's still a slight problem when I issue the offset clause. We have a table that contains 600.000 records We display them by 25 in the webpage. So, when I want the last page, which is: 600k / 25 =

Re: [PERFORM] Speed with offset clause

On 6/24/05, Yves Vindevogel [EMAIL PROTECTED] wrote: So, when I want the last page, which is: 600k / 25 = page 24000 - 1 = 23999, I issue the offset of 23999 * 25 improving this is hard, but not impossible. if you have right index created, try to reverse the order and fetch first adverts, and

[PERFORM] max_connections / shared_buffers / effective_cache_size questions

Hello, I'm a Sun Solaris sys admin for a start-up company. I've got the UNIX background, but now I'm having to learn PostgreSQL to support it on our servers :) Server Background: Solaris 10 x86 PostgreSQL 8.0.3 Dell PowerEdge 2650 w/4gb ram. This is running JBoss/Apache as well (I KNOW the bad

Re: [PERFORM] max_connections / shared_buffers / effective_cache_size

Puddle wrote: Hello, I'm a Sun Solaris sys admin for a start-up company. I've got the UNIX background, but now I'm having to learn PostgreSQL to support it on our servers :) Server Background: Solaris 10 x86 PostgreSQL 8.0.3 Dell PowerEdge 2650 w/4gb ram. This is running JBoss/Apache as well

Re: [PERFORM] Speed with offset clause

Yves Vindevogel wrote: Hi again all, My queries are now optimised. They all use the indexes like they should. However, there's still a slight problem when I issue the offset clause. We have a table that contains 600.000 records We display them by 25 in the webpage. So, when I want the last

Re: [PERFORM] max_connections / shared_buffers /

1.) shared_buffers I see lot of reference to making this the size of available ram (for the DB). However, I also read to make it the size of pgdata directory. 2.) effective_cache_size - from what I read this is the 'total' allowed memory for postgresql to use correct? So, if I am

[PERFORM] Performance - moving from oracle to postgresql

Hi: I'm beginning the push at our company to look at running postgreSQL in production here. We have a dual CPU 2.8 GHZ Xeon Box running oracle. Typical CPU load runs between 20% and 90%. Raw DB size is about 200GB. We hit the disk at roughly 15MB/s read volume and 3MB/s write.

Re: [PERFORM] max_connections / shared_buffers / effective_cache_size questions

Thanks for the feedback guys. The database will grow in size. This first client years worth of data was 85mb (test to proof of concept). The 05 datasets I expect to be much larger. I think I may increase the work_mem and maintenance_work_mem a bit more as suggested to. I'm a bit still

Fwd: [PERFORM] Speed with offset clause

Hmm, I can't do this, i'm afraid. Or it would be rather difficult My query is executed through a webpage (link to the page in a navigation bar) I do not know how many records there are (data is changing, and currently is 600k records) The only thing I could do, is doing this in a function where

Re: [PERFORM] Speed with offset clause

Hi, Indeed, I would have to do it through a function, where I check the number of pages, It puts my weakest point in the middle then. I could simply rewrite my query like you state, just to check. I think all my queries are on one table only. (I report in a website on one table, that has

Re: [PERFORM] Speed with offset clause

I just ran this query select p.* from tblPrintjobs p , (select oid from tblPrintjobs limit 25 offset 622825) as subset where p.oid = subset.oid And it seems to be a bit faster than without the subselect, probably because I'm only getting one column. The speed gain is not that high though On 24

Re: [PERFORM] Needed: Simplified guide to optimal memory configuration

For those who provided some guidance, I say thank you. You comments helped out a lot. All of our customers who are using the older release are now very pleased with the performance of the database now that we were able to give them meaningful configuration settings. I'm also pleased to see

Re: [PERFORM] Performance Tuning Article

Hi, The article seems to dismiss RAID5 a little too quickly. For many application types, using fast striped mirrors for the index space and RAID5 for the data can offer quite good performance (provided a sufficient number of spindles for the RAID5 - 5 or 6 disks or more). In fact, random read

Re: [PERFORM] Performance - moving from oracle to postgresql

There are some immediate questions from our engineers about performance - Oracle has one particular performance enhancement that Postgres is missing. If you do a select that returns 100,000 rows in a given order, and all you want are rows 99101 to 99200, then Oracle can do that very

Re: [PERFORM] parameterized LIKE does not use index

On Thu, Jun 23, 2005 at 11:55:35AM -0700, Josh Berkus wrote: Bruno, I remember some discussion about delaying planning until the first actual query so that planning could use actual parameters to do the planning. If you really want to have it check the parameters every time, I think you

Re: [PERFORM] Configurator project launched

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sounds a little similar to what's in pgAdmin CVS right now. The configuration editor can retrieve the config file and display configured and active setting concurrently, together with explanations taken from pg_settings (when not run against a