On Thu, Feb 14, 2013 at 5:31 AM, Vick Khera wrote:
>
> On Wed, Feb 13, 2013 at 4:35 PM, Kevin Grittner wrote:
>>
>> seq_page_cost = 0.1
>> random_page_cost = 0.1
>
>
> Is there any gain in setting these to the same low value, as it would to
> leave them both at 4? I thought they are just relativ
On Wed, Feb 13, 2013 at 4:35 PM, Kevin Grittner wrote:
> seq_page_cost = 0.1
> random_page_cost = 0.1
>
Is there any gain in setting these to the same low value, as it would to
leave them both at 4? I thought they are just relative numbers to each
other. And unless you're on SSD, these numbers
On Wed, Feb 13, 2013 at 2:53 PM, Tom Lane wrote:
> Carlos Henrique Reimer writes:
>> Will include the EXPLAIN ANALYZE again here:
>
>>-> Index Scan using pagpk_aux_mes, pagpk_aux_mes, pk_cadpag, pk_cadpag,
>> pk_cadpag, pagchavefunc00 on cadpag (cost=0.00..131521.88 rows=183322
>> width=62)
Sorry for the confusion, the plans from morning and evening are really
different for sure.
Let me ensure with my team that postgresql configuration is not changed
between morning and evening and will recollect the data tomorrow.
On Wed, Feb 13, 2013 at 8:34 PM, Kevin Grittner wrote:
> Carlos H
Carlos Henrique Reimer writes:
> Will include the EXPLAIN ANALYZE again here:
>-> Index Scan using pagpk_aux_mes, pagpk_aux_mes, pk_cadpag, pk_cadpag,
> pk_cadpag, pagchavefunc00 on cadpag (cost=0.00..131521.88 rows=183322
> width=62) (actual time=0.664..614.080 rows=32828 loops=1)
BTW, I
On Wed, Feb 13, 2013 at 8:23 PM, Carlos Henrique Reimer <
carlos.rei...@opendb.com.br> wrote:
>
> I've used this query just as an example but the general feeling is that
> everything takes more time to process in the evening. Evening is also the
> period with more tasks in the the database.
>
>
Wh
Carlos Henrique Reimer wrote:
> Anyway it does not seam related to statistics as the query plan
> is exactly the same for both scenarios, morning and evening:
> Morning:
> Index Scan using pagpk_aux_mes, pagpk_aux_mes, pk_cadpag,
> pk_cadpag, pk_cadpag, pagchavefunc00 on cadpag
> Evening
Carlos Henrique Reimer wrote:
> Another example that could help is this seqscan:
>
> explain analyze select sittrib8 from iparq.arript where sittrib8=33;
>
> In the evening:
> Fri Feb 8 14:00:01 BRST 2013
>
> QUERY
> PLAN
> --
Hi,
Anyway it does not seam related to statistics as the query plan is exactly
the same for both scenarios, morning and evening:
Will include the EXPLAIN ANALYZE again here:
___
Morning:
pgipm=# explain a
On Wed, Feb 13, 2013 at 10:42 AM, Carlos Henrique Reimer
wrote:
> Hi,
>
> I`m trying to figure out why a query runs in 755ms in the morning and
> 20054ms (26x) in the evening.
>
>
> Morning:
>
> Sort (cost=151845.90..152304.21 rows=183322 width=62) (actual
> time=706.676..728.080 rows=32828 loop
Tom Lane wrote:
> I'm wondering about cache effects, ie memory already contains
> desired pages in the morning (perhaps as a side-effect of queries
> run overnight) and not so much by the evening. If so it's not
> clear that additional VACUUM activity would make things better.
>
> But in any cas
Kevin Grittner writes:
> Carlos Henrique Reimer wrote:
>> I`m trying to figure out why a query runs in 755ms in the morning
>> and 20054ms (26x) in the evening.
> I would make autovacuum settings much more aggressive, or schedule
> periodic VACUUM and/or ANALYZE runs during the day.
I'm wonder
Carlos Henrique Reimer wrote:
> I`m trying to figure out why a query runs in 755ms in the morning
> and 20054ms (26x) in the evening.
I would make autovacuum settings much more aggressive, or schedule
periodic VACUUM and/or ANALYZE runs during the day.
> database size is 40GB and memory 64GB
Some issues are just funny.
Maybe lots of inserts deletes during the day?
Vacuum/analyze timing may have an impact on the planner?
Try again morning evening with vac/ana commands before the query.
Op 13-2-2013 19:42, Carlos Henrique Reimer schreef:
Hi,
I`m trying to figure out why a query run
Hi,
I`m trying to figure out why a query runs in 755ms in the morning and
20054ms (26x) in the evening.
_
Mornin
15 matches
Mail list logo
