| From: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: question on index access |
| Date: | 2002-03-15 23:32:26 |
| Message-ID: | 1016235146.26927.39.camel@jiro |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2002-03-15 at 18:23, Tom Lane wrote:
> Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> writes:
> > AFAIK, current Postgres behavior when processing SELECT queries is like
> > this:
> > (1) for each tuple in the result set, try to get an
> > AccessShareLock on it
>
> Uh, no. There are no per-tuple locks, other than SELECT FOR UPDATE
> which doesn't affect SELECT at all. AccessShareLock is taken on the
> entire table, mainly as a means of ensuring the table doesn't disappear
> from under us.
Ah, that makes sense. My mistake -- thanks for the info.
Cheers,
Neil
--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-03-16 00:50:57 | Re: pg_hba.conf and secondary password file |
| Previous Message | Tom Lane | 2002-03-15 23:23:47 | Re: question on index access |