Re: PATCH: default_index_tablespace

From: jltallon(at)adv-solutions(dot)net
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: default_index_tablespace
Date: 2015-04-16 16:50:36
Message-ID: e8dc762395ac3adc661c96a39021ed18@adv-solutions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> >
>> > 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(at)mail(dot)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-04-16 16:59:35 Re: Supporting src/test/modules in MSVC builds
Previous Message Peter Geoghegan 2015-04-16 16:43:54 Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0