Query Optimisation and TEXT fields
От | Andrew McMillan |
---|---|
Тема | Query Optimisation and TEXT fields |
Дата | |
Msg-id | 39A2EF76.4C8F32D9@catalyst.net.nz обсуждение исходный текст |
Ответы |
Re: Query Optimisation and TEXT fields
|
Список | pgsql-hackers |
I am having some problems getting optimised queries when I use TEXT fields in records. It seems that PostgreSQL is assuming that these fields are 4 bytes wide so the record width calculation is wrong and this means that all of the dependant calculations are wrong. Will it be a big deal to change teh width estimate for a record? I see that vacuum effectively collects this statistic already, but is it saved? For example, from the following vacuum we can see that the average record size on my table is approximately:(1392*BLCKSZ)/24986 or ~ 456 bytes NOTICE: --Relation story-- NOTICE: Pages 1392: Changed 0, reaped 528, Empty 0, New 0; Tup 24986: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 18161, MinLen 76, MaxLen 574; Re-using: Free/Avail. Space 111804/104284; EndEmpty/Avail. Pages 0/376. CPU 0.31s/3.00u sec. NOTICE: Index story_pkey: Pages 201; Tuples 24986: Deleted 0. CPU 0.04s/0.24u sec. On the other hand, a basic query shows that the optimiser is estimating only around 20% of that: newsroom=# explain select * from story; NOTICE: QUERY PLAN: Seq Scan on story (cost=0.00..1641.86 rows=24986 width=91) So the cost guesses are out by a factor of 5 and indexes are being used a lot less often than I would like. I have a query which does a reverse indexscan when I use LIMIT 30, giving a seemingly instant response, but switches to sequential scan and sort when I use LIMIT 35, taking around 10 seconds to return (Pentium 233). Anyone have any thoughts on how to go about fixing this? Regards, Andrew McMillan -- _____________________________________________________________________ Andrew McMillan, e-mail: Andrew@cat-it.co.nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
В списке pgsql-hackers по дате отправления: