On Mon, Jul 26, 2010 at 4:47 AM, Vlad Arkhipov wrote:
> There is a partitioned table with 2 partitions:
>
> drop table if exists p cascade;
>
> create table p (
> id bigint not null primary key,
> ts timestamp);
>
> create table p_actual ( check (ts is null) ) inherits (p);
> create table p_hist
6700tps?! Wow..
Ok, I'm impressed. May wait a bit for prices to come somewhat, but that
sounds like two of those are going in one of my production machines
(Raid 1, of course)
Yeb Havinga wrote:
> Greg Smith wrote:
>> Greg Smith wrote:
>>> Note that not all of the Sandforce drives include a
Eric Schwarzenbach writes:
> I'm wondering whether columns, in the select list of a view that is used
> in a join, which are not used either as join criteria or in the select
> list of the overall query, effect the performance of the query.
If the view gets "flattened" into the calling query th
I'm wondering whether columns, in the select list of a view that is used
in a join, which are not used either as join criteria or in the select
list of the overall query, effect the performance of the query.
In other words supposed I define a view something like
CREATE view MyView AS SELECT a,
Greg Smith wrote:
Greg Smith wrote:
Note that not all of the Sandforce drives include a capacitor; I hope
you got one that does! I wasn't aware any of the SF drives with a
capacitor on them were even shipping yet, all of the ones I'd seen
were the chipset that doesn't include one still. Have
Peter Hussey writes:
> Using the default of 1MB work_mem, the planner chooses a hash join plan :
> "Hash Left Join (cost=252641.82..11847353.87 rows=971572 width=111) (actual
> time=124196.670..280461.604 rows=968080 loops=1)"
> ...
> For the same default 1MB work_mem, a nested loop plan is bette
