Re: 9.3: load path to mitigate load penalty for checksums

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: 9.3: load path to mitigate load penalty for checksums
Дата
Msg-id CAM-w4HNXYZq6xNFu9O9bqNfLLX0wk4qwnqZnxX57MsHVDK+WLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.3: load path to mitigate load penalty for checksums  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
On Tue, Jun 12, 2012 at 5:41 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> Also it's not safe to assume that insertion heavy clients
> can be migrated to COPY.  For example, JDBC bulk loading AFAIK does
> not use COPY and even if it did wouldn't be able to decorate the
> command for a long time for most production workloads

A non-mvcc table would only be useful if you're loading the data all
at once and don't plan to load any more. So that wouldn't even be
attempting to cover all "insertion heavy clients". Just specific use
cases.

I had in mind to implement something like this for archived data such
as old partitions in partitioned table. I think data loaded in a copy
that you know is never going to be modified would be a reasonable
other case for the same codepath.

Note that this particular use case is covered by FDW as well. If the
source data is in a dense enough format you could save even the load
step by reading directly from the source. I don't think this
eliminates the idea of having a denser read-only format though.
Postgres has lots of other features like indexing and different data
representations that might be useful and would be missing from, say, a
csv source file.

--
greg


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Следующее
От: Tom Lane
Дата:
Сообщение: Re: /proc/self/oom_adj is deprecated in newer Linux kernels