Thom Brown <thom@linux.com> writes:
> The commit refers to duplicate index names, and only for UNIQUE
> indexes. This behaviour is beyond that. And how does it determine
> which index to copy? In my example, I placed an index in a different
> tablespace. That could be on a drive with very different read/write
> characteristics than the default tablespace (seek latency/sequential
> read rate/write speed etc.) and possibly with different GUC
> parameters, but there's no way for us to determine if this is the
> case, so Postgres can easily remove the more performant one.
TBH, I have no particular concern for this argument. If you created
duplicate indexes you did a dumb thing anyway; you should not be expecting
that the system's response to that situation will be remarkably
intelligent. As the comment indicates, the code in question is really
only meant to deal with a specific kind of redundancy we'd observed in
real-world CREATE TABLE commands. It's probably accidental that it gets
applied in CREATE TABLE LIKE cases, but it doesn't bother me that it is.
regards, tom lane