On Tue, 2005-05-31 at 22:31 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > If a table is created as WITHOUT OIDS, is it still possible to take
> > advantage of the physical tlist optimization?
>
> Um ... it depends. There are cases where you have to have an OID,
> and cases where you have to not have one. See ExecContextForcesOids.
Yes, the routine that inspired my question.
Where I'm leading to is this: If the physical tlist optimization is a
considerable gain, and it required OIDs, then changing the system
default to WITHOUT OIDS will cause us to lose the optimization. Yes?
Should we re-evaluate the decision to change the default?
Specifically, I'm thinking about managing large databases. Large data
tables must be created WITHOUT OIDS, which means that they will be
somewhat slower than small and medium sized tables.
You also had an idea before about using the physical tlist optimization
on an APPEND step to improve partitioned performance. That would only be
possible if all child tables had OIDs. That is unlikely to be the case,
since partitioning tends to occur in larger databases which would
definitely not reenable OIDs via the WITH OIDS option on CT.
It might be possible to optionally have a OID-like column on a per table
basis. That would limit each table to about a billion rows, which should
be sufficient with partitioning as an option. However, even in that
case, the APPEND would still require globally unique OIDs would it not?
So, I can't see a useful way to have APPEND use physical tlists.
Best Regards, Simon Riggs
