Skip site navigation (1) Skip section navigation (2)

Re: UNION ALL vs INHERITANCE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adi Alurkar <adi(at)sf(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UNION ALL vs INHERITANCE
Date: 2004-12-16 22:13:14
Message-ID: 1869.1103235194@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Adi Alurkar <adi(at)sf(dot)net> writes:
> Why does the append resulting from a inheritance take longer than one  
> resulting from  UNION ALL?

The index scan is where the time difference is:

>                       ->  Index Scan using fftiallbgrgfid_1102715649 on  
> f_f_all_base  (cost=0.00..3.52 rows=1 width=51) (actual  
> time=3.871..244.356 rows=28 loops=1)
>                             Index Cond: (group_id = 78745)
>                             Filter: (all_tidx @@ '\'mmcach\''::tsquery)

>                       ->  Index Scan using fftiallbgrgfid_1102715649 on  
> f_f_all_base  (cost=0.00..3.52 rows=1 width=51) (actual  
> time=3.714..79.996 rows=28 loops=1)
>                             Index Cond: (group_id = 78745)
>                             Filter: (all_tidx @@ '\'mmcach\''::tsquery)

One would have to suppose this is a caching effect, ie, the data is
already in RAM on the second try and doesn't have to be read from disk
again.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: David BrownDate: 2004-12-17 11:18:36
Subject: Re: Seqscan rather than Index
Previous:From: Adi AlurkarDate: 2004-12-16 20:06:46
Subject: UNION ALL vs INHERITANCE

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-12-16 22:15:13
Subject: Updates for beta/rc stamping
Previous:From: Tom LaneDate: 2004-12-16 22:08:35
Subject: Re: port report: [FAILURE] FreeBSD 6, Intel icc7

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group