On Fri, Mar 15, 2013 at 12:06 PM, Rick Otten wrote:
>>> I not convinced about the need for BBU with SSD - you *can* use them
>>> without one, just need to make sure about suitable longevity and also
>>> the presence of (proven) power off protection (as discussed
>>> previously). It is worth noting
On Fri, Mar 15, 2013 at 06:06:02PM +, Rick Otten wrote:
> >I don't think any drive that corrupts on power-off is suitable for a
> >database, but for non-db uses, sure, I guess they are OK, though you
> >have to be pretty money->constrainted to like that tradeoff.
>
> Wouldn't mission critical d
On 15.03.2013 19:31, Florian Weimer wrote:
Does it make sense to pre-sort COPY FROM input to produce long runs of
increasing values of an indexed column, or does PostgreSQL perform
this optimization on its own?
PostgreSQL doesn't do that sort of an optimization itself, so yeah, if
the random I
>> I not convinced about the need for BBU with SSD - you *can* use them
>> without one, just need to make sure about suitable longevity and also
>> the presence of (proven) power off protection (as discussed
>> previously). It is worth noting that using unproven or SSD known to be
>> lacking po
Does it make sense to pre-sort COPY FROM input to produce long runs of
increasing values of an indexed column, or does PostgreSQL perform
this optimization on its own?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.p
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
12 matches
Mail list logo
