----------------------------------------------------------------------------------------------------------------------------------------------- Index Scan using sname_unique on "testtable" (cost=0.00..34453.74 rows=8620 width=20) (actual time=77.004..537065.079 rows=74612 loops=1) Index Cond: ((sname >= 'AA'::text) AND (sname < 'AB'::text)) Filter: (sname ~~ 'AA%'::text) Total runtime: 537477.737 ms (4 rows)
Time: 537480.571 ms
Nothing you're going to do to the query is going to come up with a more effective plan than this. It's using the index after all. It's never going to be lightning fast because it has to process 75k rows.
However 75k rows shouldn't be taking nearly 10 minutes. It should be taking about 10 seconds.
I am confused about this statement. I have a table with 1.77 million rows that I use gist indexes on (TSearch) and I can pull out of it in less than 2 seconds.
Are you saying it should be taking 10 seconds because of the type of plan? 10 seconds seems like an awfullong time for this.
Sincerely,
Joshua D. Drake
That's my feeling as well, I thought the index was to blame because it will be quite large, possibly large enough to not fit in memory nor be quickly bursted up.
The 77ms before finding the first record is a bit suspicious. Have you vacuumed this table regularly? Try a VACUUM FULL VERBOSE, and send the results. You might try to REINDEX it as well, though I doubt that would help.
This table is *brand spanking new* for lack of a better term. I have the data for it in a CSV. I load the CSV up which takes a bit, then create the indexes, do a vacuum analyze verbose, and then posted the results above. I don't think running vacuum a more times is going to change things, at least not without tweaking config settings that affect vacuum. Not a single row has been inserted or altered since the initial load.. it's just a test.
I can't give vacuum stats right now because the thing is reloading
(again) with different newfs settings -- something I figure I have the
time to fiddle with now, and seldom do at other times. These numbers
though don't change much between 8K on up to 64K 'cluster' sizes. I'm
trying it now with 8K page sizes, with 8K "minimum fragment" sizes. Should speed things up a tiny bit but not enough to really affect this
query.
Do you still see a need to have the output from the vacuum?
Actually you might consider clustering the table on sname_unique. That would accomplish the same thing as the VACUUM FULL command and also speed up the index scan. And the optimizer knows (if you analyze afterwards) it so it should be more likely to pick the index scan. But currently you have to rerun cluster periodically.
Clustering is really unworkable in this situation. It would work now, in this limited test case, but using it if this were to go into production is unrealistic. It would have to happen fairly often since this table is updated frequently, which will break the clustering quickly with MVCC.
Running it often.. well.. it has 70M+ rows, and the entire table is copied, reordered, and rewritten.. so that's a lot of 'scratch space' needed. Finally, clustering locks the table..
Something I'd already considered but quickly ruled out because of these reasons..
More ideas are welcome though. ;)
-Allen
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
-- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard
---------------------------(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
