Re: [HACKERS] LOCK.tag(figuring out granularity of lock)

2003-10-05 Thread Alvaro Herrera
On Fri, Aug 08, 2003 at 03:49:36PM -0400, Bruce Momjian wrote: > Alvaro Herrera wrote: > > "Right now the sectors on the hard disk run clockwise, but I heard a rumor that > > you can squeeze 0.2% more throughput by running them counterclockwise. > > It's worth the effort. Recommended." (Gerry Pour

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-25 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-24 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-19 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-14 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-14 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

Re: [HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-14 Thread Bruce Momjian
Alvaro Herrera wrote: > "Right now the sectors on the hard disk run clockwise, but I heard a rumor that > you can squeeze 0.2% more throughput by running them counterclockwise. > It's worth the effort. Recommended." (Gerry Pourwelle) In relation to your signature, I assume you have seen this joke

Re: [HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-14 Thread Tom Lane
"Jenny -" <[EMAIL PROTECTED]> writes: > how do we check whether blockId and tupleId of LOCK.tag are valid or > invalid? Look at how LockRelation and LockPage (in src/backend/storage/lmgr/lmgr.c) set up the tags --- it might be clearer then. regards, tom lane

Re: [HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-08 Thread Alvaro Herrera
On Fri, Aug 08, 2003 at 12:15:07PM -0700, Jenny - wrote: > following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: [...] Is this on a crontab or something? It has gotten very annoying lately. -- Alvaro Herrera () "Right now the sectors on the hard disk run clockwise, but I he

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-08 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple

[HACKERS] LOCK.tag(figuring out granularity of lock)

2003-08-05 Thread Jenny -
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: "If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tuple