Re: Tablespaces on tertiary media - Mailing list pgsql-general

From Gregory Stark
Subject Re: Tablespaces on tertiary media
Date
Msg-id 877imto2gv.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Tablespaces on tertiary media  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
Responses Re: Tablespaces on tertiary media  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
List pgsql-general
"Mark Morgan Lloyd" <markMLl.pgsql-general@telemetry.co.uk> writes:

> 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?

Ah, I see what you mean now. I think you might have a problem with the planner
opening the files to do an lseek to measure how large they are. I'm not sure
if that gets triggered before or after constraint exclusion. That's the only
problem I can think of.

> 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.

Well it's not like there are any alternative plans that will avoid the need to
access the data at all. I assume the FUSE setup will always have to load the
entire file so there's no even any difference between indexed and sequential
access. (Unless the table is over 1G in which case you might want to avoid
sequential scans if index scans would avoid accessing some segments.)


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

pgsql-general by date:

Previous
From: Mark Morgan Lloyd
Date:
Subject: Re: Tablespaces on tertiary media
Next
From: Markus Schiltknecht
Date:
Subject: Re: Scalability Design Questions