>> >
>> > 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
<CAM-w4HPOASwsQMdGZqjyFHNubbUnWrUAo8ibci-97UKU=poDbg@mail.gmail.com>)
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.