| not null
Indexes:
"par_est_2012_07_08_aid_index" btree (aid)
"par_est_2012_07_08_le_index" btree (list_id, estimate) CLUSTER
Check constraints:
"par_est_2012_07_08_date_check" CHECK (date = '2012-07-08'::date)
"par_est_2012_07_date_che
Yes, the index name is par_est_2012_07_09_aid_index on the aid column. The
plan is as follows. It seems looks better than the old one, since it choose
the index scan. However, I don't think it's efficient, since it still
append the result from child tables together, then join the small table
(par_l
2012-07-08'::date) AND (date <=
'2012-07-10'::date))
-> Seq Scan on par_est_2012_07_10 e (cost=0.00..221248.96
rows=10842664 width=16)
Filter: ((date >= '2012-07-08'::date) AND (date <=
'2012-07-10'::date))
(12 rows)
On Fr
PM, AI Rumman wrote:
> Which version of Postgresql are you using?
> Have you set constraint_exclusion to parition?
>
>
> On Fri, Mar 15, 2013 at 11:02 AM, Ao Jianwang wrote:
>
>> Hi Experts,
>>
>> I found if we join the master table with other small table, the
Hi Experts,
I found if we join the master table with other small table, then the
running time is slow. While, if we join each child table with the small
table, then it's very fast. Any comments and suggestions are greatly
appreciated.
*For example, par_list table is small(about 50k rows), while p
16:11, Ao Jianwang wrote:
>
> Hi,
>
> Does any one can tell me why the same query runs against on smaller data
> is slower than bigger table. thanks very much.
>
> I am using PostgreSQL9.1.8.
>
> *t_apps_1 and t_estimate_1 are about 300M respectively, while *_l
Hi,
Does any one can tell me why the same query runs against on smaller data is
slower than bigger table. thanks very much.
I am using PostgreSQL9.1.8.
*t_apps_1 and t_estimate_1 are about 300M respectively, while *_list_1
about 10M more or less. According to the result, it need to read a lot of
