Re: PATCH: default_index_tablespace

Поиск
Список
Период
Сортировка
Искать
От
jltallon@adv-solutions.net
Тема
Re: PATCH: default_index_tablespace
Дата
Msg-id
e8dc762395ac3adc661c96a39021ed18@adv-solutions.net
Ответ на
Список
Дерево обсуждения
PATCH: default_index_tablespace jltallon@adv-solutions.net
Re: PATCH: default_index_tablespace Tom Lane <tgl@sss.pgh.pa.us>
Re: PATCH: default_index_tablespace Bruce Momjian <bruce@momjian.us>
Re: PATCH: default_index_tablespace Stephen Frost <sfrost@snowman.net>
Re: PATCH: default_index_tablespace jltallon@adv-solutions.net
Re: PATCH: default_index_tablespace Stephen Frost <sfrost@snowman.net>
Re: PATCH: default_index_tablespace Amit Kapila <amit.kapila16@gmail.com>
Re: PATCH: default_index_tablespace David Steele <david@pgmasters.net>
Re: PATCH: default_index_tablespace Greg Stark <stark@mit.edu>
>> >
>> > I'm afraid this idea is a nonstarter, because it will break 
>> existing
>> > applications, and in particular existing pg_dump output files, 
>> which
>> > expect to be able to determine an index's tablespace by setting
>> > "default_tablespace".  (It is *not* adequate that the code falls 
>> back
>> > to "default_tablespace" if the new GUC is unset; if it is set, 
>> you've
>> > still broken pg_dump.)

Got it. Thank you for the feedback.

>> The incremental value, if indeed there is any,
>> > of being able to control index positioning this way seems unlikely 
>> to
>> > justify a backwards-compatibility break of such magnitude.
>>
>> I can see why someone would want this because random I/O, which is
>> frequent for indexes, is much faster on SSD than magnetic disks.
>> (Sequential I/O is more similar for the two.)
>
> The general idea is something I've brought up previously also (I 
> believe
> it was even discussed at the Dev meeting in, uh, 2013?) so I'm not
> anxious to simply dismiss it, but it'd certainly have to be done
> correctly..


Any suggestions on how to do it "properly"?
Does Greg Stark's suggestion (at 
) 
make sense to you?
This approach might suffer from the same problem as mine, though.

It seems to me, IMVHO, a limitation in pg_dump ---since 8.0 when 
tablespace support for CREATE INDEX was implemented--- that we should 
fix.
Keeping backwards compatibility is indeed required; I just did not 
think about pg_dump at all :(


I don't mind reworking the patch or redoing it completely once there is 
a viable solution.


Thanks,

   / J.L.



В списке pgsql-hackers по дате отправления
От: Peter Geoghegan
Дата:
От: Andrew Dunstan
Дата:
FAQ