I am still in the dark due to my lack of knowledge on internal OID
management,but
i would presume that a table with OID enable and that has high load would
require
some more work from pgsql internal to maintain the OID index for the database.
So OID can be beneficial on static tables, or
Eric Lauzon [EMAIL PROTECTED] writes:
I am still in the dark due to my lack of knowledge on internal OID
management,but
i would presume that a table with OID enable and that has high load would
require
some more work from pgsql internal to maintain the OID index for the database.
There is
On Sun, 2005-05-29 at 16:17 -0400, Eric Lauzon wrote:
I am still in the dark due to my lack of knowledge on internal OID
management,but
i would presume that a table with OID enable and that has high load would
require
some more work from pgsql internal to maintain the OID index for the
On Sun, 2005-05-29 at 16:17 -0400, Eric Lauzon wrote:
So OID can be beneficial on static tables
OIDs aren't beneficial on static tables; unless you have unusual
requirements[1], there is no benefit to having OIDs on user-created
tables (see the default_with_oids GUC var, which will default to
The OID column is an extra few bytes on each row. If you don't have any
use for it (and let's face it: most of us don't), then create your
tables without OID.
Also there are some useful hacks using the oid which don't work if it
wraps around, thus preventing it from wrapping around by
What are the effect of having a table with arround 500 insert/update/delete on
two to eight table in a time frame of 2 minutes 24/24h, when you have oid
enabled versus the same setup when you dont have oid?
That deployment is done on a postgres with 8 to 9 databases, each having those
2 to 8
On Fri, 2005-05-27 at 13:05 -0400, Eric Lauzon wrote:
What are the effect of having a table with arround 500
insert/update/delete on two to eight table in a time frame of 2
minutes 24/24h, when you have oid enabled versus the same setup when
you dont have oid?
That deployment is done on a
