Re: Multiple Storage per Tablespace, or Volumes
| От | Andrew Sullivan |
|---|---|
| Тема | Re: Multiple Storage per Tablespace, or Volumes |
| Дата | |
| Msg-id | 20070219195034.GB9448@phlogiston.dyndns.org обсуждение исходный текст |
| Ответ на | Re: Multiple Storage per Tablespace, or Volumes (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Multiple Storage per Tablespace, or Volumes
Re: Multiple Storage per Tablespace, or Volumes Re: Multiple Storage per Tablespace, or Volumes Log levels for checkpoint/bgwriter monitoring |
| Список | pgsql-hackers |
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > Somehow this seems like implementing RAID within postgres, > > RAID and LVM too. I can't get excited about re-inventing those wheels > when perfectly good implementations already exist for us to sit on top of. Ok, warning, this is a "you know what would be sweet" moment. What would be nice is to be able to detach one of the volumes, and know the span of the data in there without being able to access the data. The problem that a lot of warehouse operators have is something like this: "We know we have all this data, but we don't know what we will want to do with it later. So keep it all. I'll get back to you when I want to know something." It'd be nice to be able to load up all that data once, and then shunt it off into (say) read-only media. If one could then run a query that would tell one which spans of data are candidates for the search, you could bring back online (onto reasonably fast storage, for instance) just the volumes you need to read. A -- Andrew Sullivan | ajs@crankycanuck.ca Users never remark, "Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath." --Damien Katz
В списке pgsql-hackers по дате отправления: