>
> 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=po...@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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
