| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jenny -" <nat_lazy(at)hotmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: row level lock and table level locks |
| Date: | 2003-09-09 02:33:35 |
| Message-ID: | 17296.1063074815@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jenny -" <nat_lazy(at)hotmail(dot)com> writes:
>> TupleTables are just temporary data structures to hold transiently
>> created tuples during execution of a query. There's usually one for
>> each plan node.
> The TupleTable will exist for the query from the point the query is made
> untill the transaction is committed? or does the TupleTable go away as soon
> as query is finished executing?
It goes away as soon as the query finishes.
My answer above was mistaken --- plan nodes usually allocate slots in a
single TupleTable created (and destroyed) by execMain.c, rather than
each having their own TupleTable. But it's still a query-lifetime data
structure.
> I would think the TupleTable for that query is held untill the transaction
> is committed since lock on the tuple is endtill the end of transaction
You keep looking for nonexistent locks on tuples ...
The only resources represented by a TupleTable entry are memory for
a transient tuple (if we rewrote the system today, we'd forget that
function, since short-term memory contexts can do the job better)
or a buffer pin for a tuple that's sitting in a shared disk buffer.
There is no reason to hold a buffer pin beyond the time that the tuple
might actually be referenced by the query plan.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-09-09 04:19:48 | Re: ISO 8601 "Time Intervals" of the "format with time-unit deignators" |
| Previous Message | Jenny - | 2003-09-09 01:09:33 | Re: row level lock and table level locks |