On Sat, Apr 13, 2013 at 9:01 PM, Rodrigo Barboza
wrote:
> Would it help if I changed the checkpoint_completion_target to something
> close to 0.7 (mine is the default 0.5) or raise the checkpoint_segments (it
> is 32 now)?
That depends. What are your access patterns like? Do you have 1 or 2
wr
On Sat, Apr 13, 2013 at 4:51 PM, Jeff Janes wrote:
> On Sat, Apr 13, 2013 at 10:29 AM, Rodrigo Barboza > wrote:
>
>>
>>
>> I was receiving warning messages of pgstat timeout.
>> I started looking for the solution for this problem and this doubt came
>> out.
>> But it doesn't seem to be the probl
On Sat, Apr 13, 2013 at 9:14 AM, Steve Singer wrote:
>
>>
>>
> indexTotalCost += index->pages * spc_random_page_cost / 10.0;
>
> Is driving my high costs on the inner loop. The index has 2-5 million
> pages depending on the partition . If I run this against 9.2.2 with /
> 1.0 the estimat
On Sat, Apr 13, 2013 at 10:29 AM, Rodrigo Barboza
wrote:
>
>
> I was receiving warning messages of pgstat timeout.
> I started looking for the solution for this problem and this doubt came
> out.
> But it doesn't seem to be the problem.
>
Usually that just means that you are dirtying pages faster
On Sat, 13 Apr 2013 11:21:19 -0400
Tom Lane wrote:
> The planner realizes that about 1/200th of the table satisfies the
> "ord" condition, so it estimates that the first plan will require
> scanning about 2000 entries in the pkey index to get 10 results. So
> that looks significantly cheaper tha
On Fri, Apr 12, 2013 at 10:20 PM, Jeff Janes wrote:
> On Friday, April 12, 2013, Rodrigo Barboza wrote:
>
>> Hi guys.
>> I compiled my postrges server (9.1.4) with default segment size (16MB).
>> Should it be enough? Should I increase this size in compilation?
>>
>
> To recommend that you deviate
On 13-04-12 09:20 PM, Jeff Janes wrote:
On Thursday, April 11, 2013, Steve Singer wrote:
I think the reason why it is picking the hash join based plans is
because of
Index Scan using table_b_1_ptid_orgid_ym_unq on table_b_1 b
(cost=0.00..503.86 rows=1 width=10) (actual time=0.0
On 13/04/13 18:25, Rikard Pavelic wrote:
> I was investigating some performance issues and stumbled upon this behavior:
>
> create table main_table (i serial primary key, data varchar, ord int);
> create view main_view_order as select m.i, m.data, m.ord from main_table m
> order by m.i desc;
>
>
Rikard Pavelic writes:
> I was investigating some performance issues and stumbled upon this behavior:
> create table main_table (i serial primary key, data varchar, ord int);
> create view main_view_order as select m.i, m.data, m.ord from main_table m
> order by m.i desc;
> insert into main_tabl
I was investigating some performance issues and stumbled upon this behavior:
create table main_table (i serial primary key, data varchar, ord int);
create view main_view_order as select m.i, m.data, m.ord from main_table m
order by m.i desc;
insert into main_table select i, i::text, i/10 from ge
10 matches
Mail list logo
