Re: Query plan and Inheritance. Weird behavior
От | Stephan Szabo |
---|---|
Тема | Re: Query plan and Inheritance. Weird behavior |
Дата | |
Msg-id | 20030122183939.I5182-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Query plan and Inheritance. Weird behavior (John Lange <lists@darkcore.net>) |
Ответы |
Re: Query plan and Inheritance. Weird behavior
|
Список | pgsql-performance |
On 22 Jan 2003, John Lange wrote: > Creating child tables by inheriting from another table doesn't really do > what I consider to be 'true' inheritance, at least not in the way I > expected as a programmer. > > Postgres seems to create "child" tables by first fully duplicating the > parent table and then adding the new columns to it. It then links the > tables internally some how so that a query on a parent table also > queries the child tables. That pretty much sums up my understanding of it. [snip] > In this way the parent table would not need to know, nor would it care > about child tables in any way (just like inheritance in most programming > languages). If done this way a select on a parent table would only > require the retrieval of a single row and a select on a child table > would only require the retrieval of two rows (one in the child table and > one in the parent table). As opposed to needing one row from a select on a child table and effectively a union all when selecting from the parent. There are up and down sides of both implementations, and I haven't played with it enough to speak meaningfully on it. > I don't pretend to know the intricacies of Postgres performance but this > is the way I'm interpreting the data from the explains. As a side note, for a better understanding of timings, explain analyze is much better than plain explain which only gives the plan and estimates.
В списке pgsql-performance по дате отправления: