Re: [PERFORM] COPY vs INSERT

2005-05-06 Thread Jim C. Nasby
On Wed, May 04, 2005 at 10:22:56PM -0400, Tom Lane wrote: Also, there is a whole lot of one-time-per-statement overhead that can be amortized across many rows instead of only one. Stuff like opening the target table, looking up the per-column I/O conversion functions, identifying trigger

Re: [PERFORM] Bad choice of query plan from PG 7.3.6 to PG 7.3.9

2005-05-06 Thread Jona
Thank you for the swift reply. The test server is hardly ever vacuumed as it in general sees very limited traffic. vacuum is only necessary if the server sees a lot of write operations, i.e. update, delete, insert right? What explains the different choice of query plans then? As can be seen

Re: [PERFORM] COPY vs INSERT

2005-05-06 Thread Dennis Bjorklund
On Fri, 6 May 2005, Jim C. Nasby wrote: Has thought been given to supporting inserting multiple rows in a single insert? DB2 supported: INSERT INTO table VALUES( (1,2,3), (4,5,6), (7,8,9) ); I'm not sure how standard that is or if other databases support it. The sql

Re: [PERFORM] Bad choice of query plan from PG 7.3.6 to PG 7.3.9

2005-05-06 Thread Jona
Results of VACUUM VERBOSE from both servers Test server: comm=# VACUUM VERBOSE StatCon_Tbl; INFO: --Relation public.statcon_tbl-- INFO: Pages 338: Changed 338, Empty 0; Tup 11494: Vac 0, Keep 0, UnUsed 0. Total CPU 0.02s/0.00u sec elapsed 0.04 sec. INFO: --Relation pg_toast.pg_toast_179851--

Re: [PERFORM] Bad choice of query plan from PG 7.3.6 to PG 7.3.9

2005-05-06 Thread Christopher Kings-Lynne
You didn't do analyze. Chris Jona wrote: Results of VACUUM VERBOSE from both servers Test server: comm=# VACUUM VERBOSE StatCon_Tbl; INFO: --Relation public.statcon_tbl-- INFO: Pages 338: Changed 338, Empty 0; Tup 11494: Vac 0, Keep 0, UnUsed 0. Total CPU 0.02s/0.00u sec elapsed 0.04

Re: [PERFORM] COPY vs INSERT

2005-05-06 Thread Harald Fuchs
In article [EMAIL PROTECTED], Dennis Bjorklund [EMAIL PROTECTED] writes: On Fri, 6 May 2005, Jim C. Nasby wrote: Has thought been given to supporting inserting multiple rows in a single insert? DB2 supported: INSERT INTO table VALUES( (1,2,3), (4,5,6), (7,8,9) ); I'm not sure how

Re: [PERFORM] Bad choice of query plan from PG 7.3.6 to PG 7.3.9

2005-05-06 Thread Jona
Now with analyze Test Server: comm=# VACUUM ANALYZE VERBOSE StatCon_Tbl; INFO: --Relation public.statcon_tbl-- INFO: Pages 338: Changed 0, Empty 0; Tup 11494: Vac 0, Keep 0, UnUsed 0. Total CPU 0.02s/0.00u sec elapsed 1.98 sec. INFO: --Relation pg_toast.pg_toast_179851-- INFO: Pages

Re: [PERFORM] COPY vs INSERT

2005-05-06 Thread Bruno Wolff III
On Fri, May 06, 2005 at 01:51:29 -0500, Jim C. Nasby [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 10:22:56PM -0400, Tom Lane wrote: Also, there is a whole lot of one-time-per-statement overhead that can be amortized across many rows instead of only one. Stuff like opening the target

Re: [PERFORM] COPY vs INSERT

2005-05-06 Thread Tom Lane
Bruno Wolff III [EMAIL PROTECTED] writes: Jim C. Nasby [EMAIL PROTECTED] wrote: Has thought been given to supporting inserting multiple rows in a single insert? It's on the TODO list. I don't remember anyone bringing this up for about a year now, so I doubt anyone is actively working on

Re: [PERFORM] [SQL] ORDER BY Optimization

2005-05-06 Thread Rosser Schwarz
while you weren't looking, Derek Buttineau|Compu-SOLVE wrote: I'm hoping this is the right place to send this. The PostgreSQL Performance list, pgsql-performance@postgresql.org would be more appropriate. I'm copying my followup there, as well. As for your query, almost all the time is actually

Re: [PERFORM] [SQL] ORDER BY Optimization

2005-05-06 Thread Derek Buttineau|Compu-SOLVE
Thanks for the response :) That's 50-ish ms versus 80-odd seconds. It seems to me a merge join might be more appropriate here than a nestloop. What's your work_mem set at? Off-the-cuff numbers show the dataset weighing in the sub-ten mbyte range. Provided it's not already at least that big, and

[PERFORM] Whence the Opterons?

2005-05-06 Thread Mischa Sandberg
After reading the comparisons between Opteron and Xeon processors for Linux, I'd like to add an Opteron box to our stable of Dells and Sparcs, for comparison. IBM, Sun and HP have their fairly pricey Opteron systems. The IT people are not swell about unsupported purchases off ebay. Anyone care

Re: [PERFORM] Whence the Opterons?

2005-05-06 Thread Ian Meyer
Mischa, What kind of budget are you on? penguincomputing.com deals with Opteron servers. I looked at a couple of their servers before deciding on a HP DL145. Ian On 5/6/05, Mischa Sandberg [EMAIL PROTECTED] wrote: After reading the comparisons between Opteron and Xeon processors for Linux,

Re: [PERFORM] Whence the Opterons?

2005-05-06 Thread Steve Poe
IBM, Sun and HP have their fairly pricey Opteron systems. The IT people are not swell about unsupported purchases off ebay. Mischa, I certainly understand your concern, but the price and support sometimes go hand-in-hand. You may have to pick your batttles if your want more bang for the buck

Re: [PERFORM] Whence the Opterons?

2005-05-06 Thread Gavin M. Roy
Please wait a week before buying Sun v20z's or v40z's from off of Ebay (j/k). (As I'm in the process of picking up a few) From everything I hear the v20z/v40z's are a great way to go and I'll know more in 15 days or so. Regards, Gavin Steve Poe wrote: IBM, Sun and HP have their fairly pricey