September 10th, 2003, 04:03 PM
Optimising a char select
I'm making the switch from MySQL to Postgres. Everything's been going fine, but I've now run into a rather slow query. I've a table with 10,000+ entries, and a CHAR(4) column called Code that I'm using in my select statements. When I do a search for a large(ish) number of items, it's taking 4+ seconds to return results. This was never a problem in MySQL, and so I'm thinking there must be a way to index the table, or rewrite my query.
Thanks for any help.
SELECT FabricID, Code FROM Fabric WHERE Code IN ('X295','X296','X297','X298','X299','X300','X301','X302','X303','X304','X306','X400','X403','X404',' X405','X4
Last edited by kurious; September 10th, 2003 at 04:32 PM.
September 10th, 2003, 05:00 PM
Why would you do a partial index on such a narrow column? Just index the whole thing.
But possibly the main problem here is not indexing, but the use of IN(). IN is a notoriously slow construct in SQL anyway, and often is an unnecessary way to approach things when you have a more relational system.
Let me ask, how do you arrive at this large list of values you are placing in the IN() clause? Is it the result of a query? If so, you can often it with a subquery, such as "WHERE column IN(SELECT column FROM table WHERE [condition])".
But, with some knowledge of your database structure and design, we could probably arrive at an even more efficient way to do this. Generally, a query such as yours is evidence that some database design issues need to be re-thought.
One other reason this query might not perform as fast as MySQL might be because MySQL tables often have fulltext indexing turned on by default. PostgreSQL has a couple ways to achieve fulltext indexing, but they are external modules that need to be installed.
September 10th, 2003, 06:29 PM
Well, I arrived at the large list of values because IN has never been slow in Oracle or MySQL; it's the way I've always done things up until now. I'm importing data from another database via some CSV files, and so the codes I'm trying to select aren't the result of any Postgres query. I'm basically testing to see whether items already exist in the table. I could query individually, but I'm afraid that's not always going to be an effective solution in the long run.
I've been trying to get my work to dump MySQL for a long time, and I was hoping to do so with minimum change to my coding style. Oh, well. Time to crank my brain into gear and learn something, I suppose
Would a fulltext index make any difference on such a small column? I don't know how they work.
September 10th, 2003, 10:21 PM
Really, the correct/fast way to do this is import the data to a temp table, using the COPY command (which is extremely fast), and then run standard queries to determine what to do with files. The added benefit of this is that it can be done completely in PostgreSQL, without needing an external programming environment. In fact, it can even be done with a stored procedure, which precompiles the behavior for more speed.
Do it... Learning serious database concepts is always worth it .
Probably not... it was just a thought.
Anyway, before we get too worried about PostgreSQL's capabilities, here are a couple other things to consider:
1. First, check out how your query works with the index you just created. You might even try EXPLAIN on your query, to see what ugliness it reports.
2. Is PostgreSQL running on Windows, with Cygwin? If so, then that's the problem in a nutshell. PostgreSQL only performs well on Linux/Unix for the moment. Native windows versions are coming soon.
3. Is postgresql.conf set to the default configuration, or have you done any tweaking for performance? Hint: tweak, please... the default configuration is very conservative, and would probably even run on a 486 with 16 MB of RAM. Increase the buffers, cache limits, etc...
4. What version of PostgreSQL are you running? You might want to consider moving to PostgreSQL 7.4 beta2. Even though it is still beta, it is very stable, and has been tested for almost a year. 7.4 has substantially improved performance of IN() and a few other constructs. The full release of 7.4 should be out within a month or so.
So, after taking parts 1-4 into account above, let's see how the query runs after you are though. Enjoy.
(P.S. You might want to search through the PostgreSQL forum for topics like "performance" and "postgresql.conf".)
September 11th, 2003, 08:02 AM
Oh, I used to know one or two serious database concepts Two years of MySQLing has made me instantly think, "I'll just fire up PHP to get this done" Doing it all in the database seems like a totally left-field idea at the moment.
I'm using a rather old version of Linux (7.2) to run Postgres 7.3.4, but I'll stick 7.4 onto the machine today. Once I've done that I'll take a look at tweaking the config, and then figure out how to interpret the EXPLAIN output. If that still doesn't work, I'll bother you some more, but in the meantime thank you very much for writing such complete responses to my posts.
September 11th, 2003, 09:43 AM
One final note: if this is a production system, you should still be careful about using PostgreSQL 7.4Beta2. I am not in the slightest way worried that it will randomly corrupt your data, but still, you should make frequent backups, and do things carefully until the final release is out. For one thing, do NOT assume that when the final release is out, you can just install it over your beta version: do a complete dump of your data, wipe your data directory, install the final release, and then do a complete restore. You might not need to do things this way, but it is better to be careful.
September 11th, 2003, 12:11 PM
Installed the newest beta, reinserted all of the data, increased shared memory... with a very slight imporvement in performance. Then I went to the manual and started reading up on how to make sense of EXPLAIN results. The first point in "Examing index usage" is "Always run ANALYZE first."
The query is now flying. Somebody hit me.
September 11th, 2003, 12:17 PM
lol... that's my fault. I forgot to mention ANALYZE and VACUUM ANALYZE.