Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres --

2004-09-14 Thread Iain
of data involved, and queries are normally date qualified. That sounds interesting. I have to admit that I havn't touched iheritance in pg at all yet so I find it hard to imagine how this would work. If you have a chance, would you mind elaborating on it just a little? Regards Iain

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres --

2004-09-15 Thread Iain
derived from a parent table makes a lot of sense. regards Iain - Original Message - From: Joe Conway [EMAIL PROTECTED] To: Iain [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 16, 2004 1:07 PM Subject: Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres --

2004-09-16 Thread Iain
still do all that that if you wanted to, by building the predicated view with UNION ALL of each of the child tables. regards Iain - Original Message - From: Joe Conway [EMAIL PROTECTED] To: Christopher Browne [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 16, 2004 2:17 PM

Re: [PERFORM] Caching of Queries

2004-09-27 Thread Iain
have guessed, my vote is for implementing a query cache that includes plans. I have no specific preference as to data caching. It doesn't seem to be so important to me. Regards Iain On Thu, Sep 23, 2004 at 08:29:25AM -0700, Mr Pink wrote: Not knowing anything about the internals of pg, I

Re: [PERFORM] Caching of Queries

2004-09-27 Thread Iain
future PG/Oracle/Hypersonic (my 3 favourite DBMSs) application development anyway. Regards Iain - Original Message - From: "Tom Lane" [EMAIL PROTECTED] To: "Iain" [EMAIL PROTECTED] Cc: "Jim C. Nasby" [EMAIL PROTECTED]; [EMAIL P

Re: [PERFORM] can't handle large number of INSERT/UPDATEs

2004-10-26 Thread Iain
Turbo linux 7 sems to be agreeing with Curtis, bi: ブロックデバイスに送られたブロック (blocks/s)。 bo: ブロックデバイスから受け取ったブロック (blocks/s)。 Sorry it's in Japanese but bi says "blocks sent to block device" and bo is "blocks received from

Re: [PERFORM] postgresql amd-64

2004-11-07 Thread Iain
it offhand. If anyone has opinions about that, I'd be happy to hear. regards Iain - Original Message - From: Daniel Ceregatti [EMAIL PROTECTED] To: Merlin Moncure [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 06, 2004 3:23 AM Subject: Re: [PERFORM] postgresql amd-64 I

Re: [PERFORM] FW: Index usage

2004-11-30 Thread Iain
be amenable to useful comparative searching (I didn't read any of the earlier posts so if that isn't the case, just ignore this). If this is the case, try storing the data in a date column and see what happens then. regards Iain test=# explain analyse select * from bigtable where item_id = 1000

Re: [PERFORM] FW: Index usage

2004-11-30 Thread Iain
but if it is, I'd expect it to use a -MM-DD format which is what I see here. Something like ... WHERE date= to_date('11/03/04','DD/MM/YY') regards Iain - Original Message - From: BBI Edwin Punzalan [EMAIL PROTECTED] To: 'Iain' [EMAIL PROTECTED]; 'gnari' [EMAIL PROTECTED]; [EMAIL

Re: [PERFORM] Alternatives to Dell?

2004-12-01 Thread Iain
I always say 'If you pay for quality it only hurts once', but then again I don't equate high price with high quality ;-) - Original Message - From: Geoffrey [EMAIL PROTECTED] Something to be said for the old saying, 'you get what you pay for.' ---(end of

Re: [PERFORM] Normalization or Performance

2004-12-02 Thread Iain
Hi, without knowing much about your system, it seems to me that the current status of a client should be represented by a status code on the client record. History is the list of *past* status codes. The full history, including the current status of a client would be obtained

Re: [PERFORM] Howto Increased performace ?

2004-12-26 Thread Iain
Iain ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] Howto Increased performace ?

2004-12-27 Thread Iain
checkpoint_segments 8 In theory, effective cache size is the amount of memory left over for the OS to cache the filesystem after running all programs and having 100 users connected, plus a little slack. regards Iain - Original Message - From: Amrit Angsusingh [EMAIL PROTECTED] To: Iain [EMAIL

Re: [PERFORM] Howto Increased performace ?

2004-12-27 Thread Iain
is to reduce swapping by tuning your memory usage for busy times. Also, I heard that (most?what versions?) 32 bit linux kernals are slow at handling more than 2GB memory so a kernal upgrade might be worth considering. regards Iain ---(end of broadcast

Re: [PERFORM] Howto Increased performace ?

2004-12-27 Thread Iain
you can, then you can decide if that is fast enough for you. More memory might help, but I can't say for sure. There are many other things to consider. I suggest that you spend some time reading through the performance and maybe the admin lists. regards Iain - Original Message - From

Re: [PERFORM] Howto Increased performace ?

2004-12-27 Thread Iain
when the system is busy. In the the not so bad case, the effective cache size estimate will just be completely wrong. Maybe a global sort memory limit would be a good idea, I don't know. regards Iain Iain wrote: sort_mem 4096 (=400MB RAM for 100 connections) If I understand correctly, memory usage

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

2005-01-20 Thread Iain
guess. Nonetheless, I would love to see this kind of functionality in postgres. Regards Iain - Original Message - From: Jim C. Nasby [EMAIL PROTECTED] To: Bruno Almeida do Lago [EMAIL PROTECTED] Cc: 'Mitch Pirtle' [EMAIL PROTECTED]; pgsql-performance@postgresql.org Sent: Friday, January

Re: [PERFORM] How can I make use of both CPUs in a dual processor

2005-02-09 Thread Iain
processing time, but if there are contention problems then it could conceivably get much worse. regards Iain - Original Message - From: Alex [EMAIL PROTECTED] To: John A Meinel [EMAIL PROTECTED] Cc: pgsql-performance@postgresql.org Sent: Thursday, February 10, 2005 12:00 AM Subject: Re

Re: [PERFORM] seq scan cache vs. index cache smackdown

2005-02-14 Thread Iain
Hi Rod, Any solution fixing buffers should probably not take into consideration the method being performed (do you really want to skip caching a sequential scan of a 2 tuple table because it didn't use an index) but the volume of data involved as compared to the size of the