Tom Lane wrote:
>
> Don Baccus <dhogaza@pacifier.com> writes:
> > Of course, if I've understood past postings to this list,
> > Postgres also fsynch's after read-only selects, too,
>
> I recently learned something about this that I hadn't understood before.
> When a tuple is written out during an insert/update transaction, it is
> marked as not definitely committed (since of course Postgres can't know
> whether you'll abort the transaction later). The ID of the transaction
> that wrote it is stored with it. Subsequently, whenever the tuple is
> scanned, the backend has to go to the "transaction log" to see if that
> transaction has been committed yet --- if not, it ignores the tuple.
>
> As soon as the transaction is known to be committed, the next operation
> that visits that tuple will mark it as "known committed", so as to avoid
> future consultations of the transaction log. This happens *even if the
> current operation is a select*. That is why selects can cause disk
> writes in Postgres.
Right. But we could avoid fsync for such write operation, i.e.
do write call but not fsync. This will not avoid real disk writes
but select will not wait for them.
Vadim
