Re: [HACKERS] [hackers]development suggestion needed
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] [hackers]development suggestion needed |
Дата | |
Msg-id | 3.0.1.32.20000113181933.010771d0@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [hackers]development suggestion needed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Multiple Spindles ( Was: Re: [HACKERS] [hackers]development suggestion
needed )
Re: [HACKERS] [hackers]development suggestion needed |
Список | pgsql-hackers |
At 09:01 PM 1/13/00 -0500, Tom Lane wrote: >As you say, you can fake it manually with symbolic links, but that's >a kluge. Yes, it is. Or worse :) > >The "database location" stuff that Peter and Thomas have been arguing >about is intended to allow a single postmaster to control databases that >are in multiple physical locations --- but there seems to be some debate >as to whether it works ;-). (I never tried it.) In any case, we don't >currently have any official provision for controlling location at finer >than database level. It'd be nice to be able to push individual tables >around, I suppose. Putting indices on different spindles than the tables is known to significantly speed up the Ars Digita Community system under load with Oracle. Systems like this, used to back busy web sites, stuff things into tables many times a second. As I mentioned, I've played around a bit with postgres using "ln" and it does indeed help boost the number of inserts my (paltry, two-spindle) system could sustain. The selects that such sites spew forth are handled wonderfully by Postgres now, with MVCC and the change that stops the update of pg_log after read-only selects. My site's still in the experimental stage, being used by a couple dozen folks to record bird distribution data in the Pacific NW, so I don't personally have real-world data to get a feeling for how important this might become. Still, Oracle DBA docs talk a lot about it so in some real-world scenarios being able to distribute tables and indices on different spindles must pay off. > >This wouldn't require a new storage manager, since presumably you'd >still be using the Unix-filesystem storage manager. The trick would be >to allow a path rather than just a base file name to be specified >per-relation. I'm not sure if it'd be hard or not. Probably, all the >system tables would have to stay in the database's default directory, >but maybe user tables could be given path names without too much >trouble... I've looked into it, actually, and have reached the same conclusion. Including the bit about keeping system tables in the database's default directory. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: