Re: Fast insertion indexes: why no developments

Поиск
Список
Период
Сортировка
От Leonardo Francalanci
Тема Re: Fast insertion indexes: why no developments
Дата
Msg-id 1383152656593-5776418.post@n5.nabble.com
обсуждение исходный текст
Ответ на Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Jeff Janes wrote
> You could periodically merge older partitions into larger tables, index
> those aggregated tables, then transactionally disinherit the old
> partitions
> and inherit the new aggregated one.  This would keep the value of K down,
> at the expense of re-writing data multiple times (but all method write
> data
> multiple times, some just hide it from you).

Forgot to add:

I thought also that we could:

- use the RAM as tablespace for indexes, and move the indexes later (but
postgresql doesn't handle very well a machine crash in this case... it would
be cool to create an index as "recreate on crash"...)
- use unlogged tables and turn those to logged to speed up somehow the
insertion; I actually started to write a patch for it, but making it work
for replication was too hard (not that I'm using replication, but it
wouldn't be accepted for "wal_level = minimal"). But this wouldn't solve the
problem anyway.




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Fast-insertion-indexes-why-no-developments-tp5776227p5776418.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Leonardo Francalanci
Дата:
Сообщение: Re: Fast insertion indexes: why no developments
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)