Re: Doubts about oid - Mailing list pgsql-general
Hi,
> Even in Oracle, I don't believe rowid bypasses
> indexes, its more like an implicit SERIAL PRIMARY KEY field.
Well, I understand the point is not very relevant, since oid is not similar to rowid. In Oracle, index scans are bypassed if we use rowid.
1)Access by unique index
SQL> select * from myt where id=200;
Execution Plan
----------------------------------------------------------
Plan hash value: 1325982734
--------------------------------------------------------------------------------
----
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
----
| 0 | SELECT STATEMENT | | 1 | 65 | 1 (0)| 00:00:
01 |
| 1 | TABLE ACCESS BY INDEX ROWID| MYT | 1 | 65 | 1 (0)| 00:00:
01 |
|* 2 | INDEX UNIQUE SCAN | MYDX | 1 | | 1 (0)| 00:00:
01 |
--------------------------------------------------------------------------------
2) Access by rowid
SQL> select * from myt where rowid='AAAH9iAAEAAAAafADH';
ID
----------
NAME
--------------------------------------------------------------------------------
200
REFCON$
Execution Plan
----------------------------------------------------------
Plan hash value: 4204525950
--------------------------------------------------------------------------------
---
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
---
| 0 | SELECT STATEMENT | | 1 | 77 | 1 (0)| 00:00:0
1 |
| 1 | TABLE ACCESS BY USER ROWID| MYT | 1 | 77 | 1 (0)| 00:00:0
Regards,
Jayadevan
DISCLAIMER:
"The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect."
> Even in Oracle, I don't believe rowid bypasses
> indexes, its more like an implicit SERIAL PRIMARY KEY field.
Well, I understand the point is not very relevant, since oid is not similar to rowid. In Oracle, index scans are bypassed if we use rowid.
1)Access by unique index
SQL> select * from myt where id=200;
Execution Plan
----------------------------------------------------------
Plan hash value: 1325982734
--------------------------------------------------------------------------------
----
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
----
| 0 | SELECT STATEMENT | | 1 | 65 | 1 (0)| 00:00:
01 |
| 1 | TABLE ACCESS BY INDEX ROWID| MYT | 1 | 65 | 1 (0)| 00:00:
01 |
|* 2 | INDEX UNIQUE SCAN | MYDX | 1 | | 1 (0)| 00:00:
01 |
--------------------------------------------------------------------------------
2) Access by rowid
SQL> select * from myt where rowid='AAAH9iAAEAAAAafADH';
ID
----------
NAME
--------------------------------------------------------------------------------
200
REFCON$
Execution Plan
----------------------------------------------------------
Plan hash value: 4204525950
--------------------------------------------------------------------------------
---
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
---
| 0 | SELECT STATEMENT | | 1 | 77 | 1 (0)| 00:00:0
1 |
| 1 | TABLE ACCESS BY USER ROWID| MYT | 1 | 77 | 1 (0)| 00:00:0
Regards,
Jayadevan
DISCLAIMER:
"The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect."
pgsql-general by date: