Обсуждение: inheritance performance
Wondering ... From a performance standpoint, is it a bad idea to use inheritance simply as a tool for easy database building. That is for creating tables that share the same columns but otherwise are unrelated. For example, let's say I have the following set of columns that are common to many of my tables. objectid int, createdby varchar(32), createddate timestamp ... and let's say I create a table with these columns just so that I can then create other tables that inherit this table so that I have these columns in it without having to respecify them over and over again separately for each table that contains them. From my understanding, all the data for these columns in all the child tables will be stored in this one parent table and that, furthermore, there is a "hidden" column in the parent table called tableoid that allows postgres to determine which row is stored in which child table. Given that, is there a performance hit for queries on the child tables because postgres has to effectively put a condition on every query based on the tableoid of the given child table? In other words, if say child table A has 10 million rows in it and child B has 2 rows in it. Will a query on child table B be slowed down by the fact that it inherits from the same table as A. I'm sure the answer is absolutely yes, and so I guess I'm just looking for corroboration. Maybe I'll be surprised! Thanks a bunch, Ken
ken <southerland@samsixedd.com> writes: > >From my understanding, all the data for these columns in all the child > tables will be stored in this one parent table No, all the data is stored in the child table. > and that, furthermore, there is a "hidden" column in the parent table called > tableoid that allows postgres to determine which row is stored in which > child table. That's true. > Given that, is there a performance hit for queries on the child tables > because postgres has to effectively put a condition on every query based on > the tableoid of the given child table? There's a performance hit for the extra space required to store the tableoid. This means slightly fewer records will fit on a page and i/o requirements will be slightly higher. This will probably only be noticeable on narrow tables, and even then probably only on large sequential scans. There's also a slight performance hit because there's an optimization that the planner does normally for simple queries that isn't currently done for either UNION ALL or inherited tables. I think it's planned to fix that soon. > In other words, if say child table A has 10 million rows in it and child > B has 2 rows in it. Will a query on child table B be slowed down by the > fact that it inherits from the same table as A. I'm sure the answer is > absolutely yes, and so I guess I'm just looking for corroboration. No, it isn't slowed down by the records in A. It's slightly slower because it is an inherited table, but that impact is the same regardless of what other tables inherit from the same parent and how many records are in them. -- greg
On Fri, 2005-01-21 at 08:14, Greg Stark wrote: > ken <southerland@samsixedd.com> writes: > > > >From my understanding, all the data for these columns in all the child > > tables will be stored in this one parent table > > No, all the data is stored in the child table. So if you perform a "select * from parent" then does postgres internally create a union between all the child tables and return you the results of that? ken
ken <southerland@samsixedd.com> writes: > On Fri, 2005-01-21 at 08:14, Greg Stark wrote: > > ken <southerland@samsixedd.com> writes: > > > > > >From my understanding, all the data for these columns in all the child > > > tables will be stored in this one parent table > > > > No, all the data is stored in the child table. > > So if you perform a "select * from parent" then does postgres internally > create a union between all the child tables and return you the results > of that? Essentially, yes. -- greg
> So if you perform a "select * from parent" then does postgres internally > create a union between all the child tables and return you the results > of that? Basically, yes. Kind of. Chris
On Fri, 21 Jan 2005, Greg Stark wrote: > There's also a slight performance hit because there's an optimization that the > planner does normally for simple queries that isn't currently done for either > UNION ALL or inherited tables. I think it's planned to fix that soon. Can you explain me in more details what kind of optimization is missing in that case?
Ioannis Theoharis <theohari@ics.forth.gr> writes: > Can you explain me in more details what kind of optimization is missing in > that case? Uh, no I can't really. It was mentioned on the mailing list with regards to UNION ALL specifically. I think it applied to inherited tables as well but I wouldn't know for sure. You could search the mailing list archives for recent discussions of partitioned tables. In any acse it was a purely technical detail. Some step in the processing of the data that could be skipped if there weren't any actual changes to the data being done or something like that. It made a small but noticeable difference in the runtime but nothing that made the technique infeasible. -- greg
Greg Stark <gsstark@mit.edu> writes:
> ken <southerland@samsixedd.com> writes:
>> From my understanding, all the data for these columns in all the child
>> tables will be stored in this one parent table
> No, all the data is stored in the child table.
Correct ...
>> and that, furthermore, there is a "hidden" column in the parent table called
>> tableoid that allows postgres to determine which row is stored in which
>> child table.
> That's true.
> There's a performance hit for the extra space required to store the tableoid.
Bzzzt ...
tableoid isn't actually stored anywhere on disk. It's a pseudo-column
that is generated during row fetch. (It works for all tables, not only
inheritance children.)
>> Given that, is there a performance hit for queries on the child tables
>> because postgres has to effectively put a condition on every query based on
>> the tableoid of the given child table?
AFAIR, a query directed specifically to a child table is *completely*
unaware of the fact that that table is a child. Only queries directed
to a parent table, which have to implicitly UNION in the children, pay
any price for inheritance.
regards, tom lane