Thread: Tables Without OIDS and its effect

Dear all ,

I have created my tables without OIDS  now my doubts are :
1.  Will this speed up the data insertion process
2. Though I have not written any code in my any of the pgsql functions
which depend on OIDS
  1. Will without OIDS the functions behave internally differently
  2. Will my application break at any point
3. I decided to  work with out OIDS because
  1. It has a limit of  -2147483648 to +2147483647
  2 Due to this limitation I would not like to drop recreate my
database because it is a bit difficult/dirty process

All links and suggestion pertaining to OIDS are most welcome my mail box
is at your  disposal and dont  hassitate to
drop a two line comment.
-----------------------
My Sys Config:
RH                9.0
PostgreSQL  7.3.4
GCC             3.2.2
PHP              4.3.4
----------------------
Regards,
V Kashyap

Sai Hertz And Control Systems <sank89@sancharnet.in> writes:
> I have created my tables without OIDS  now my doubts are :
> 1.  Will this speed up the data insertion process

Slightly. It means that each inserted row will be 4 bytes smaller (on
disk), which in turn means you can fit more tuples on a page, and
therefore you'll need fewer pages and less disk space. However, I'd be
surprised if the performance improvement is very significant.

> 2. Though I have not written any code in my any of the pgsql functions
> which depend on OIDS
>   1. Will without OIDS the functions behave internally differently
>   2. Will my application break at any point

No.

BTW, we intend to phase out the use of OIDs for user tables in the
long term. There have been a few threads on -hackers that discuss the
plans for doing this.

-Neil

Hello  Neil Conway,

We are doing some test on our applications and will let know the community  if without OIDS we could gain
more speed .

2. Though I have not written any code in my any of the pgsql functions
which depend on OIDS 1. Will without OIDS the functions behave internally differently 2. Will my application break at any point   

No.

BTW, we intend to phase out the use of OIDs for user tables in the
long term. There have been a few threads on -hackers that discuss the
plans for doing this. 

This was a relief  for us all , but an the same time we have found one incompatibility

This incompatibility is with
1.  StarOffice 7.0
2. OpenOffice 1.1
and the incompatibility is when I retrieve data into Star SpreadSheet or  Open Office SpreadSheet
I am greeted with an error field OID  not found.
Though these both are connecting to PostgreSQL  7.3.4 (Linux GCC 3.x) via psqlODBC  07.02.0003
On the Same time WinSQL connects as usual via psqlODBC  07.02.0003  and is working fine.

Though  this does not  effect us a lot since we are using PHP to show and retrieve data
We are posting this such that any one relying totally on OpenOffice for data  retrieve and display
better know this ,

Our Test config was:
--------------------------
Client :-
O.S           Win XP (No service pack)
OpenOffice    1.1  Windows version
StarOffice      7.0   Eval Pack
psqlODBC 07.02.0003
Server  :-
OS                      RH 9.0 kernel-2.4.20-24.9
PostgreSQL       7.3.4

Please if anyone has a different story  while using  WITHOUT  OIDS please let us and every one know .


Regards,
V Kashyap

Neil Conway <neilc@samurai.com> writes:
> BTW, we intend to phase out the use of OIDs for user tables in the
> long term.

I don't believe anyone has proposed removing the facility altogether.
There's a big difference between making the default behavior be not
to have OIDs and removing the ability to have OIDs.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
> I don't believe anyone has proposed removing the facility
> altogether.  There's a big difference between making the default
> behavior be not to have OIDs and removing the ability to have OIDs.

Right, that's what I had meant to say. Sorry for the inaccuracy.

-Neil