Re: Fast insertion indexes: why no developments - Mailing list pgsql-hackers

From Leonardo Francalanci
Subject Re: Fast insertion indexes: why no developments
Date
Msg-id 1383152656593-5776418.post@n5.nabble.com
Whole thread Raw
In response to Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
List 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 by date:

Previous
From: Leonardo Francalanci
Date:
Subject: Re: Fast insertion indexes: why no developments
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)