Re: skip WAL on COPY patch
От | Robert Haas |
---|---|
Тема | Re: skip WAL on COPY patch |
Дата | |
Msg-id | CA+TgmoZ6zEDoST7MDdLkQ4QtsB+dyYNuKcpEtjVKLz=wQLm9Rw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: skip WAL on COPY patch (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
On Tue, Aug 23, 2011 at 4:51 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mar ago 23 17:43:13 -0300 2011: >> On Tue, Aug 23, 2011 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Robert Haas <robertmhaas@gmail.com> writes: >> >> What I think would be really interesting is a way to make this work >> >> when the table *isn't* empty. In other words, have a COPY option that >> >> (1) takes an exclusive lock on the table, (2) writes the data being >> >> inserted into new pages beyond the old EOF, and (3) arranges for crash >> >> recovery or transaction abort to truncate the table back to its >> >> previous length. Then you could do fast bulk loads even into a table >> >> that's already populated, so long as you don't mind that the table >> >> will be excusive-locked and freespace within existing heap pages won't >> >> be reused. >> > >> > What are you going to do with the table's indexes? >> >> Oh, hmm. That's awkward. > > If you see what I proposed, it's simple: you can scan the new segment(s) > and index the tuples found there (maybe in bulk which would be even > faster). You can do that much even if you just append to the file - you don't need variable-length segments to make that part work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: