Re: VACUUM kills Index Scans ?!

Поиск
Список
Период
Сортировка
От Gerald Gutierrez
Тема Re: VACUUM kills Index Scans ?!
Дата
Msg-id 5.0.2.1.0.20010315125737.0282b9c0@kalador.com
обсуждение исходный текст
Ответ на Re: VACUUM kills Index Scans ?!  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-sql
>There is an undocumented little factoid here: CREATE INDEX will update
>(some of) the planner stats, but only if it finds some data in the
>table.  CREATE INDEX on an empty table leaves the initial default
>numbers alone.  This may be contributing to your confusion, but it was
>deemed necessary ...

I understand now; it makes sense. I'll be using a number of tables that are 
initially very small, perhaps 5 or 10 records. But I expect that the tables 
will grow very quickly to several tens (or hundreds) of thousands of 
records. It seems reasonable to me that the table should then be set up to 
use index scan right from the beginning so that as the table grows the 
index scan will become more useful. Thus, the correct sequence for me is 
probably:

>         CREATE TABLE
>         CREATE INDEX
>         load data

I also understand that VACUUM and VACUUM ANALYZE takes a significant amount 
of time and locks the tables that it works on. Does it do locking and 
unlocking per table as it goes through them (i.e. only lock while it's 
reading the table) or does it do something else? If the locks are for large 
amounts of time I'll have to shut down my application to avoid connections 
from timing out and JDBC exceptions from being thrown.

Thanks for your help :)





В списке pgsql-sql по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: VACUUM kills Index Scans ?!
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: PL/pgSQL "compilation error"