> > The more general and "standard" way to go are TABLESPACEs.
> > But probably proposed feature will be compatible with
> > tablespaces, when we'll got them:
>
> Will it be? I'm afraid of creating a backwards-compatibility
> problem for ourselves when it comes time to implement tablespaces.
As I said, INDEX_LOCATION in CREATE DATABASE could mean location
of default tablespace for indices in future and one will be able
to override tablespace for particular index with TABLESPACE
clause in CREATE INDEX command.
> At the very least I'd like to see some information demonstrating
> how much benefit there is to this proposed patch, before we
> consider whether to adopt it. If there's a significant performance
> benefit to splitting a PG database along the table-vs-index divide,
> then it's interesting as a short-term improvement ... but Jim didn't
> even make that assertion, let alone provide evidence to back it up.
Agreed. He mentioned significant performance difference but it would
be great to see results of pgbench tests with scaling factor of >= 10.
Jim?
Also, after reviewing patch I have to say that it will NOT work
with WAL. Jim, please do not name index' dir as "<TBL_NODE>_index".
Instead, just use different TBL_NODE for indices (different number).
It's not good to put if(reln->rd_rel->relkind == RELKIND_INDEX)
stuff into storage manager - only two numbers (tblnode & relnode)
must be used to identify file, no any other logical information
totally unrelated to storage issues.
Vadim
