From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Mark Morgan Lloyd" <markMLl(dot)pgsql-general(at)telemetry(dot)co(dot)uk> |
Cc: | <pgsql-general(at)PostgreSQL(dot)org> |
Subject: | Re: Tablespaces on tertiary media |
Date: | 2007-09-14 12:28:48 |
Message-ID: | 877imto2gv.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Mark Morgan Lloyd" <markMLl(dot)pgsql-general(at)telemetry(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2007-09-14 12:38:12 | Re: oracle rank() over partition by queries |
Previous Message | Markus Schiltknecht | 2007-09-14 12:28:34 | Re: Scalability Design Questions |