Re: question on error during COPY FROM
От | Adrian Klaver |
---|---|
Тема | Re: question on error during COPY FROM |
Дата | |
Msg-id | fc42e147-2cf5-7e4d-2375-2a13d6a8ecb4@aklaver.com обсуждение исходный текст |
Ответ на | Re: question on error during COPY FROM (Rakesh Kumar <rakeshkumar464a3@gmail.com>) |
Список | pgsql-general |
On 08/23/2016 07:06 AM, Rakesh Kumar wrote: > Is it true that one datafile in PG can only belong to one object (table/index) Yes, assuming by datafile you mean an on disk file. Though one object may have many in disk files associated with it: https://www.postgresql.org/docs/9.5/static/storage-file-layout.html Details start just under Table 63-1. Contents of PGDATA > > On Tue, Aug 23, 2016 at 9:55 AM, Francisco Olarte > <folarte@peoplecall.com> wrote: >> On Tue, Aug 23, 2016 at 2:32 PM, Ilya Kazakevich >> <Ilya.Kazakevich@jetbrains.com> wrote: >>>> does that mean that I should always execute a VACUUM to recover the >>>> wasted space when an error is triggered or will the auto-vacuum mechanism >>>> do the job by itself ? >>> If you have autovacuum enabled it will clean up tablespace. However, space will not be returned to filesystem but willbe reused by database. >>> You may run VACUUM FULL manually to return it to filesystem. >> >> A normal vacuum may also return some space, specially after a big bulk >> load, see second paragraph of 23.1.2 the URL you posted: >>> https://www.postgresql.org/docs/9.1/static/routine-vacuuming.html >> >> Where it says "However, it will not return the space to the operating >> system, except in the special case where one or more pages at the end >> of a table become entirely free and an exclusive table lock can be >> easily obtained.". A big aborted bulk load may just fit the case, as >> it may put a lot of tuples at new pages at the end and be executed in >> a low-load period where the lock is easier to acquire. >> >> >> Francisco Olarte. >> >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: