Re: Tablespaces on tertiary media
От | Mark Morgan Lloyd |
---|---|
Тема | Re: Tablespaces on tertiary media |
Дата | |
Msg-id | fcdtth$4kf$1@pye-srv-01.telemetry.co.uk обсуждение исходный текст |
Ответ на | Re: Tablespaces on tertiary media (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Tablespaces on tertiary media
|
Список | pgsql-general |
Gregory Stark wrote: >> Where does PostgreSQL stand with storing /really/ large amounts of data >> offline? Specifically, if a FUSE is used to move a tablespace to something like >> a tape archiver can the planner be warned that access might take an extended >> period? > > No, Postgres can't deal with this. You'll have to dump the tables with pg_dump > or COPY or something like that and then drop them from the database. If you > need them again you have to load them again. > > Actually if the tables are missing but nobody tries to access them (including > autovacuum) then nothing will notice they're missing. But if you do try to > access them you'll get an error. And if you leave it in this situation too > long your database will shut down from getting too close to transaction > wraparound. Thanks. If the tables were in a tablespace that was stored on something that looked like a conventional filesystem would the server code be prepared to wait the minutes that it took the operating system and FUSE implementation to load the tables onto disc? The earlier work e.g. http://www.vldb.org/conf/1996/P156.PDF apparently warned the planner about long-latency devices but that's probably unnecessary if the application program was aware that a table had been partitioned by age and accessing old data could be slow. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
В списке pgsql-general по дате отправления: