Re: PATCH: default_index_tablespace
От
jltallon@adv-solutions.net
Тема
Re: PATCH: default_index_tablespace
Дата
Msg-id
e8dc762395ac3adc661c96a39021ed18@adv-solutions.net
Ответ на
Re: PATCH: default_index_tablespace (Stephen Frost)
Список
Дерево обсуждения
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 по дате отправления