Re: Tablespaces on tertiary media

From: Mark Morgan Lloyd <markMLl(dot)pgsql-general(at)telemetry(dot)co(dot)uk>
To: pgsql-general(at)PostgreSQL(dot)org
Subject: Re: Tablespaces on tertiary media
Date: 2007-09-14 12:13:35
Message-ID: fcdtth$4kf$1@pye-srv-01.telemetry.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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]

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Markus Schiltknecht 2007-09-14 12:28:34 Re: Scalability Design Questions
Previous Message Phoenix Kiula 2007-09-14 10:21:15 Re: Issue with uninstalling postgres 8.1.9