From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | Don Baccus <dhogaza(at)pacifier(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] [hackers]development suggestion needed |
Date: | 2000-01-14 15:11:26 |
Message-ID: | 29354.947862686@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>> The selects that such sites spew forth are handled wonderfully
>> by Postgres now, with MVCC and the change that stops the update
>> of pg_log after read-only selects.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Does plain 6.5.3 handle read-only selects in this way ?
AFAIR that logic is in 6.5.*. (Vadim would remember better, since he
put it in.) But keep in mind that a SELECT is read-only just to the
extent that it is hitting previously committed tuples. The first visit
to a newly committed-good or newly committed-dead tuple will cause an
update and write-back of the tuple's status flags --- whether that visit
happens in SELECT or anything else.
It occurs to me that the no-log-update logic could probably be improved
on. The test to see whether a log update is needed looks at whether any
buffers have been written. A SELECT that marks someone else's tuples as
known-committed will look like it needs to be committed in pg_log
... but it doesn't really need it. Perhaps Vadim is planning to fix
this in the WAL rewrite.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-01-14 15:12:06 | Re: [HACKERS] Copy from/to asymmetry |
Previous Message | The Hermit Hacker | 2000-01-14 15:05:53 | Re: [HACKERS] [hackers]development suggestion needed |