Leon Mergen wrote:
> On 3/19/08, Erik Jones <erik@myemma.com> wrote:
>
>> >> Excuse me for bumping this up again, but I still don't understand how
>> >> to use this approach to sequentially walk through all different child
>> >> tables in one select, without having to JOIN these tables all the
>> >> time
>> >
>> > Apparently a UNION all solved this problem -- sorry for the noise.
>>
>>
>> If you have the child tables INHERITing from the parent, then a simple
>>
>> SELECT parent.* FROM parent;
>>
>> would be equivalent to manually spelling out a UNION ALL that
>> explicitly lists all of the tables.
>>
>
> But this will only display the information that is common for all the
> child tables -- if I also want to display all the information that is
> specific for the child tables, as I understand it, I have to use a
> UNION ALL and merge all the child tables together this way.
>
> The EXPLAIN of this query:
>
> Append (cost=0.00..2169.52 rows=34376 width=94)
> -> Seq Scan ON child1 (cost=0.00..1824.71 rows=34371 width=94)
> -> Seq Scan ON child2 (cost=0.00..1.05 rows=5 width=56)
>
> Regards,
>
> Leon Mergen
>
>
What I think you desire is more in the form of:
SELECT id, foo, bar, NULL AS "baz"
FROM child1
UNION ALL
SELECT id, foo, NULL, baz
FROM child2.
I think if you compare it to I/O volume, the joins will not cause many
additional I/Os as long as the indexes on "id" for tables child1 and
child2 will fit into memory.
- Joris
