On Fri, Aug 2, 2013 at 2:51 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> Yep. Added the indexes and performance went right into the dumper. New
>> plan on new table with old data added in random order now looks like
>> the old table, only worse because it's on a slower drive. Just to be
>> comp
Sergey Burladyan writes:
> Hot standby:
...
> ' -> Index Only Scan using items_user_id_idx on public.items
> (cost=0.00..24165743.48 rows=200673143 width=8) (actual
> time=56064.499..56064.499 rows=1 loops=1)'
> 'Output: public.items.user_id'
> 'Index
Jeison Bedoya wrote:
> memory ram: 128 GB
> cores: 32
>
> max_connections: 900
> temp_buffers = 512MB
In addition to the other comments, be aware that temp_buffers is
the limit of how much RAM *each connection* can acquire to avoid
writing temporary table data to disk. Once allocated to a
con
Scott Marlowe writes:
> Yep. Added the indexes and performance went right into the dumper. New
> plan on new table with old data added in random order now looks like
> the old table, only worse because it's on a slower drive. Just to be
> complete here's the plan: http://explain.depesz.com/s/PYH N
On Fri, Aug 2, 2013 at 1:58 PM, Scott Marlowe wrote:
> On Fri, Aug 2, 2013 at 1:31 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I extracted all the data like so:
>>> select * into dba.pp_test_wide from original table;
>>> and get this query plan from explain analyze:
>>> http://explain.depes
On Fri, Aug 2, 2013 at 1:31 PM, Tom Lane wrote:
> Scott Marlowe writes:
>> I extracted all the data like so:
>> select * into dba.pp_test_wide from original table;
>> and get this query plan from explain analyze:
>> http://explain.depesz.com/s/EPx which takes 20 minutes to run.
>> If I extract it
Alvaro Herrera writes:
> Tom Lane escribió:
>> It calls get_variable_range, which only looks at the pg_statistic entries.
> Uh? It's right there in line 2976 in HEAD.
Meh. You're right, I was thinking of this bit in get_variable_range()
/*
* XXX It's very tempting to try to use the a
Scott Marlowe writes:
> I extracted all the data like so:
> select * into dba.pp_test_wide from original table;
> and get this query plan from explain analyze:
> http://explain.depesz.com/s/EPx which takes 20 minutes to run.
> If I extract it this way:
> select tree_sortkey, product_name, deleted_
Tom Lane escribió:
> Jeff Janes writes:
> > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan
> > wrote:
> >> If I not mistaken, may be two code paths like this here:
> >> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity ->
> >> get_actual_variable_range -> index_getnext
> >> (
Jeff Janes writes:
> On Fri, Aug 2, 2013 at 2:58 AM, Sergey Burladyan wrote:
> >
> > PS: I think my main problem is here:
> > select min(user_id) from items;
> > min
> > -
> >1
> > (1 row)
> >
> > Time: 504.520 ms
>
> That is a long time, but still 100 fold less than the planner is taki
On Thu, Aug 1, 2013 at 7:22 PM, Scott Marlowe wrote:
> On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>>> to it to address this issue. I just want to know should I
>>
>>> A: upgrade to 8.4.17
>>>
Tom Lane writes:
> Jeff Janes writes:
> > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan
> > wrote:
> >> If I not mistaken, may be two code paths like this here:
> >> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity ->
> >> get_actual_variable_range -> index_getnext
> >> (
Jeff Janes writes:
> On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan wrote:
>> If I not mistaken, may be two code paths like this here:
>> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity ->
>> get_actual_variable_range -> index_getnext
>> (2) scalargtsel -> scalarineqsel -> i
On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan wrote:
> I also find this trace for other query:
> explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
>
>
> If I not mistaken, may be two code paths like this here:
> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_se
On Fri, Aug 2, 2013 at 2:58 AM, Sergey Burladyan wrote:
>
> PS: I think my main problem is here:
> select min(user_id) from items;
> min
> -
>1
> (1 row)
>
> Time: 504.520 ms
That is a long time, but still 100 fold less than the planner is taking.
What about max(user_id)?
>
> also, i c
Good day,
I have a performance issue when JOINing a view within another view more than
once.
The query takes over three seconds to execute, which is too long in this case.
It's not a problem if the tables are nearly empty, but that isn't the case on
the production database.
I suspect the pla
On 08/02/2013 03:22 AM, Scott Marlowe wrote:
> On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>>> to it to address this issue. I just want to know should I
>>> A: upgrade to 8.4.17
>>> or
>>> B: cr
17 matches
Mail list logo
