Hi Tom, Rumman
Here I use two levels of partition. That's, par_est is first partitioned by
monthly (such as par_est_2012_07, ...), then for each monthly child table,
we create the daily partition table (such as par_est_2012_07_01).
And, actually,
I did some test on that. The result is as follows.
Ao Jianwang writes:
> 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.
https://wiki.postgresql.org/wiki/Slow_Query_Qu
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
Hi Rumman,
I think it works. Please see the following result. Thanks.
dailyest=# explain select * from par_est e where e.date BETWEEN
'2012-07-08' and '2012-07-10'
;
QUERY PLAN
On Fri, Mar 15, 2013 at 11:09 AM, Ao Jianwang wrote:
> Hi Rumman,
>
> Thanks for your response. I follow the guide to build the partition. The
> settings should be good. See the following result. Any insight? thanks.
>
> dailyest=# select version();
>
Hi Rumman,
Thanks for your response. I follow the guide to build the partition. The
settings should be good. See the following result. Any insight? thanks.
dailyest=# select version();
version
-
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
