| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Neil Conway" <neilc(at)samurai(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: advancing snapshot's xmin |
| Date: | 2008-03-26 15:05:50 |
| Message-ID: | 87lk45le41.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Consider a data loading job which has millions of INSERT statements in a file.
>> Currently if you put them all in a transaction it takes a single snapshot and
>> runs them all with the same snapshot.
>
>> If you reset xmin whenever you have no live snapshots then that job would be
>> doing that between every INSERT statement.
>
> These statements are 100% nonsense.
Uhm, yeah, I somehow didn't write was I was thinking. I didn't mean to say we
would be taking a new snapshot for each INSERT but that we would be resetting
xmin for each INSERT. Whereas currently we only set xmin once when we set the
serializable snapshot.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Browne | 2008-03-26 15:11:56 | Re: PostgreSQL Replication with read-only access to standby DB |
| Previous Message | Tom Lane | 2008-03-26 15:02:06 | Re: Script binaries renaming |