 | | From: | ken | | Subject: | inheritance performance | | Date: | Fri, 21 Jan 2005 00:19:05 -0800 |
|
|
 | 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
| | From: | ken | | Subject: | Re: inheritance performance | | Date: | Fri, 21 Jan 2005 09:58:39 -0800 |
|
|
| On Fri, 2005-01-21 at 08:14, Greg Stark wrote:
> ken 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
| | From: | Christopher Kings-Lynne | | Subject: | Re: inheritance performance | | Date: | Fri, 21 Jan 2005 18:15:16 +0000 |
|
|
| > 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|
|
| | From: | Greg Stark | | Subject: | Re: inheritance performance | | Date: | 21 Jan 2005 13:16:09 -0500 |
|
|
| ken writes:
> On Fri, 2005-01-21 at 08:14, Greg Stark wrote:
> > ken 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
|
|
| | From: | Greg Stark | | Subject: | Re: inheritance performance | | Date: | 21 Jan 2005 23:22:13 -0500 |
|
|
| Ioannis Theoharis 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
| | From: | Greg Stark | | Subject: | Re: inheritance performance | | Date: | 21 Jan 2005 11:14:12 -0500 |
|
|
|
ken 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
| | From: | Tom Lane | | Subject: | Re: inheritance performance | | Date: | Sat, 22 Jan 2005 15:22:22 -0500 |
|
|
| Greg Stark writes:
> ken 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
|
| | From: | Ioannis Theoharis | | Subject: | Re: inheritance performance | | Date: | Sat, 22 Jan 2005 03:09:28 +0200 (EET) |
|
|
|
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?
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
