Re: Tablespaces on tertiary media

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Tablespaces on tertiary media
Дата
Msg-id 877imto2gv.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Tablespaces on tertiary media  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
Ответы Re: Tablespaces on tertiary media  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
Список 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 по дате отправления:

Предыдущее
От: Mark Morgan Lloyd
Дата:
Сообщение: Re: Tablespaces on tertiary media
Следующее
От: Markus Schiltknecht
Дата:
Сообщение: Re: Scalability Design Questions