Re: [PERFORM] Performance Optimization for Dummies 2 - the SQL

2006-10-06 Thread Carlo Stonebanks
This didn't work right away, but DID work after running a VACUUM FULL. In other words, i was still stuck with a sequential scan until after the vacuum. I turned autovacuum off in order to help with the import, but was perfoming an ANALYZE with every 500 rows imported. With autovacuum off for i

Re: [PERFORM] Performance Optimization for Dummies 2 - the SQL

2006-10-06 Thread Scott Marlowe
On Fri, 2006-10-06 at 11:44, Carlo Stonebanks wrote: > This didn't work right away, but DID work after running a VACUUM FULL. In > other words, i was still stuck with a sequential scan until after the > vacuum. > > I turned autovacuum off in order to help with the import, but was perfoming > an

Re: [PERFORM] Performance Optimization for Dummies 2 - the SQL

2006-10-06 Thread Merlin Moncure
On 10/6/06, Scott Marlowe <[EMAIL PROTECTED]> wrote: On Fri, 2006-10-06 at 11:44, Carlo Stonebanks wrote: > This didn't work right away, but DID work after running a VACUUM FULL. In > other words, i was still stuck with a sequential scan until after the > vacuum. > > I turned autovacuum off in or

Re: [PERFORM] Performance Optimization for Dummies 2 - the SQL

2006-10-06 Thread Carlo Stonebanks
> how did you determine that it is done every 500 rows? this is the The import program pages the import table - it is currently set at 500 rows per page. With each page, I run an ANALYZE. > default autovacuum paramater. if you followed my earlier > recommendations, you are aware that autovacuum

[PERFORM] Simple join optimized badly?

2006-10-06 Thread Craig A. James
I have two tables, SAMPLE and HITLIST that when joined, generate a monsterous sort. HITLIST_ROWS has about 48,000 rows SAMPLE has about 16 million rows The joined column is indexed in SAMPLE HITLIST_ROWS is a scratch table which is used a few times then discarded. HITLIST_ROWS has no index