Re: [PATCH] Simple progress reporting for COPY command
От | Tomas Vondra |
---|---|
Тема | Re: [PATCH] Simple progress reporting for COPY command |
Дата | |
Msg-id | 1562ca9b-ffb5-e5e9-0399-33db90dbe153@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Simple progress reporting for COPY command (Josef Šimánek <josef.simanek@gmail.com>) |
Ответы |
Re: [PATCH] Simple progress reporting for COPY command
Re: [PATCH] Simple progress reporting for COPY command Re: [PATCH] Simple progress reporting for COPY command |
Список | pgsql-hackers |
On 1/5/21 11:02 AM, Josef Šimánek wrote: > I'm attaching the whole patch since commitfest failed to ingest the > last incremental on CI. > Yeah, the whole patch needs to be attached for the commitfest tester to work correctly - it can't apply pieces from multiple messages, etc. Anyway, I pushed this last version of patch, after a couple more tweaks, mainly to the docs - one place used pg_stat_copy_progress, the section was not indexed properly, and so on. I see Matthias proposed to change "lines" to "tuples" - I only saw the message after pushing, but I probably wouldn't make that change anyway. The CSV docs seem to talk about lines, newlines etc. so it seems fine. If not, we can change that. One more question, though - I now realize the lines_processed ignores rows skipped because of BEFORE INSERT triggers. I wonder if that's the right thing to do? Imagine you know the number of lines in a file. You can't really use (lines_processed / total_lines) to measure progress, because that may ignore many "skipped" rows. So maybe this should be changed to count all rows. OTOH we still have bytes_processed. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: