Re: [PERFORM] my boss want to migrate to ORACLE

Is it set to write back or write through? Also, you may want to look at lowering the stripe size. The default on many RAID controllers is 128k, but for PostgreSQL 8k to 32k seems a good choice. But that's not near as important as the cache setting being write back. On Mon, 2004-08-02 at 15:18,

Re: [PERFORM] my boss want to migrate to ORACLE

It may be worth pricing up expansion options e.g. 256M or more. The other path to consider is changing RAID5 -> RAID10 if your card supports it. However, I would recommend reducing that shared_buffers setting and doing your performance measurements *again* - before changing anything else. This is

Re: [PERFORM] Page Miss Hits

Rod Taylor wrote: | ARC still helps, since it makes sure the shared_buffers don't all get | flushed from the useful small datasets when a seq scan gets executed. I'm still not convinced. Why the last backend alive, have to throw away bunch of memory copied in the SHM? And again, the ARC is a replac

Re: [PERFORM] my boss want to migrate to ORACLE

oups, i changed for RAID 10(strip and mirror) -Original Message- From: James Thornton [mailto:[EMAIL PROTECTED] Sent: 2 aout, 2004 17:32 To: Stephane Tessier Cc: 'Scott Marlowe'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PERFORM] my boss want to migrate to ORACLE Stephane T

Re: [PERFORM] my boss want to migrate to ORACLE

Stephane Tessier wrote: I checked and we have a 128 megs battery backed cache on the raid controller... we have space for more ram(we use 2 gigs on possibility of 3 gigs) iowait is very high 98% --> look like postgresql wait for io access raid5 -->raid0 if i'm right raid5 use 4 writes(parity,data,

Re: [PERFORM] Page Miss Hits

> | ARC still helps, since it makes sure the shared_buffers don't all get > | flushed from the useful small datasets when a seq scan gets executed. > > I'm still not convinced. Why the last backend alive, have to throw away > bunch of memory copied in the SHM? And again, the ARC is a replacement >

Re: [PERFORM] my boss want to migrate to ORACLE

I checked and we have a 128 megs battery backed cache on the raid controller... -Original Message- From: Scott Marlowe [mailto:[EMAIL PROTECTED] Sent: 30 juillet, 2004 11:15 To: Stephane Tessier Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PERFORM] my boss want to migrate to ORAC

Re: [PERFORM] Page Miss Hits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Marlowe wrote: | On Mon, 2004-08-02 at 10:43, Gaetano Mendola wrote: | |>Scott Marlowe wrote: |> |>>On Mon, 2004-08-02 at 02:11, Ioannis Theoharis wrote: |>> |>> |>>>Hi, i would like to answer if there is any way in postgres to find the |>>>page m

Re: [PERFORM] Page Miss Hits

Scott Marlowe wrote: On Mon, 2004-08-02 at 02:11, Ioannis Theoharis wrote: Hi, i would like to answer if there is any way in postgres to find the page miss hits caused during a query execution. Is there something like explain analyze with the page miss hits??? You're making a basic assumption that

Re: [PERFORM] Page Miss Hits

On Mon, 2004-08-02 at 02:11, Ioannis Theoharis wrote: > Hi, i would like to answer if there is any way in postgres to find the > page miss hits caused during a query execution. > > > Is there something like explain analyze with the page miss hits??? You're making a basic assumption that is (at l

Re: [PERFORM] What kind of performace can I expect and how to

On Mon, 2004-08-02 at 06:21, Joost Kraaijeveld wrote: > Hi all, > > My system is a PostgreSQL 7.4.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) > 20020903 (Red Hat Linux 8.0 3.2-7). It has a Pentium III-733 Mhz with 512 MB ram. It > is connected to my workststation (dual XEON 1700 with 1 Gb

Re: [PERFORM] No index usage with "left join"

On Mon, 2004-08-02 at 06:08, [EMAIL PROTECTED] wrote: > We have a "companies" and a "contacts" table with about 3000 records > each. > > We run the following SQL-Command which runs about 2 MINUTES !: > > SELECT count(*) FROM contacts LEFT JOIN companies ON contacts.sid = > companies.intfield01 >

Re: [PERFORM] SSD Drives

Thanks I found the same info on the tigi and like what I saw. I also spoke with a consulting firm that has used them and also says good things, but they have not tried it with postgres. I will post an analysis of performance once we have the equipment ordered and installed. -Original Message-

Re: [PERFORM] What kind of performace can I expect and how to measure?

> Hi Merlin, > > > The 9206 ms time is what the database actually spent > > gathering the data and sending it to you. This is non-negotiable unless > you bump up > > hardware, etc, or fetch less data. This time usually scales linearly > > (or close to it) with the size of the dataset you fetch.

Re: [PERFORM] No index usage with "left join"

Rod Taylor <[EMAIL PROTECTED]> writes: >> How can I force the usage of the indexes when using "left join". > Anyway, we can be fairly sure this isn't PostgreSQL 7.4 (which would > likely choose a far better plan -- hash join rather than nested loop) Indeed, the lack of any join-condition line in

Re: [PERFORM] No index usage with "left join"

> SELECT count(*) FROM contacts LEFT JOIN companies ON contacts.sid = > companies.intfield01 > > contacts.sid (type text, b-tree index on it) > companies.intfield01 (type bigint, b-tree index on it) > How can I force the usage of the indexes when using "left join". Or > any other SQL construct th

Re: [PERFORM] No index usage with

G u i d o B a r o s i o wrote: > TIP 9: the planner will ignore your desire to choose an index scan if your >joining column's datatypes do not match And this is fixed in 7.5/8.0. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (6

Re: [PERFORM] What kind of performace can I expect and how to measure?

Hi Merlin, > The 9206 ms time is what the database actually spent > gathering the data and sending it to you. This is non-negotiable unless you bump up > hardware, etc, or fetch less data. This time usually scales linearly > (or close to it) with the size of the dataset you fetch. > > The 40638

Re: [PERFORM] No index usage with

TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match Greetz, Guido > Cannot you do a cast in your query? Does that help with using the indexes? > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTE

Re: [PERFORM] What kind of performace can I expect and how to measure?

Joost wrote: > My system is a PostgreSQL 7.4.1 on i686-pc-linux-gnu, compiled by GCC gcc > (GCC) 20020903 (Red Hat Linux 8.0 3.2-7). It has a Pentium III-733 Mhz > with 512 MB ram. It is connected to my workststation (dual XEON 1700 with > 1 Gb RAM) with a 100 Mb switched network. > > I have a tab

[PERFORM] What kind of performace can I expect and how to measure?

Hi all, My system is a PostgreSQL 7.4.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 20020903 (Red Hat Linux 8.0 3.2-7). It has a Pentium III-733 Mhz with 512 MB ram. It is connected to my workststation (dual XEON 1700 with 1 Gb RAM) with a 100 Mb switched network. I have a table with 31 co

Re: [PERFORM] No index usage with "left join"

Cannot you do a cast in your query? Does that help with using the indexes? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: maandag 2 augustus 2004 14:09 To: [EMAIL PROTECTED] Subject: [PERFORM] No index usage with "left join" We have

[PERFORM] No index usage with "left join"

We have a "companies" and a "contacts" table with about 3000 records each. We run the following SQL-Command which runs about 2 MINUTES !: SELECT count(*) FROM contacts LEFT JOIN companies ON contacts.sid = companies.intfield01 contacts.sid (type text, b-tree index on it) companies.intfield01 (ty

[PERFORM] Page Miss Hits

Hi, i would like to answer if there is any way in postgres to find the page miss hits caused during a query execution. Is there something like explain analyze with the page miss hits??? ---(end of broadcast)--- TIP 3: if posting/reading through U