From: | Mark Steben <mark(dot)steben(at)drivedominion(dot)com> |
---|---|
To: | Alexander Shaburov <shab2(at)mail(dot)ru> |
Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Long running query in new production, not so long in old |
Date: | 2019-03-28 12:39:29 |
Message-ID: | CADyzmyw5OsxUQ0zhaN4xBdv9tze2yqh+fB1fTEFfj81_KFkx4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Thank you Alex for your response. I do appreciate your taking the time as I
am under a time schedule.
My question has more to do with an Interpretion of what the BUFFERS: SHARED
HIT notification means within the explain and some insight as to why it
can be so different when run in similar environments. I am running postgres
9.4 btw.
On Thu, Mar 28, 2019 at 3:45 AM Alexander Shaburov <shab2(at)mail(dot)ru> wrote:
> Hi!
>
> Make the same shared buffer value for example. Disable any activity except
> you client query. Make query twice. Second one should be during about < 1
> min.
>
> If not, so it isnt problem shared buffer. My be processor count. If query
> will be faster, so in real situation you have any activity on db, that take
> away buffers from using query.
> Alex
> 28.03.2019 1:27, Mark Steben пишет:
>
> Good evening
>
> We are moving to a new VM environment (expedient) and have one query that
> typically runs in 22 - 25 seconds in our old environment, but is running in
> about 1 hour, 20 minutes in our new. I'd like some insight as to why the
> explain is showing shared buffer hits numbering over 113 milliion
> in the new environment and only 445 thousand in the old. I have sent the
> explains along with the table descriptions, row counts, the one function
> that I know causes the bottleneck, the query, some relevant configuration
> settings in postgresql conf (identical in both environments)
> and a listing from top in both environments, showing memory, shared
> memory, and cpu.
>
> Everything seems to be identical or close, except for the shared buffer
> count in the explain.
> Any insight would be appreciated.
>
> Thank you,
>
>
> --
> *Mark Steben*
> Database Administrator
> @utoRevenue <http://www.autorevenue.com/> | Autobase
> <http://www.autobase.net/>
> CRM division of Dominion Dealer Solutions
> 95D Ashley Ave.
> West Springfield, MA 01089
> t: 413.327-3045
> f: 413.383-9567
>
> www.fb.com/DominionDealerSolutions
> www.twitter.com/DominionDealer
> www.drivedominion.com <http://www.autorevenue.com/>
>
>
>
>
>
>
--
*Mark Steben*
Database Administrator
@utoRevenue <http://www.autorevenue.com/> | Autobase
<http://www.autobase.net/>
CRM division of Dominion Dealer Solutions
95D Ashley Ave.
West Springfield, MA 01089
t: 413.327-3045
f: 413.383-9567
www.fb.com/DominionDealerSolutions
www.twitter.com/DominionDealer
www.drivedominion.com <http://www.autorevenue.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2019-03-28 12:56:16 | Re: Long running query in new production, not so long in old |
Previous Message | Brad Nicholson | 2019-03-28 12:38:50 | Re: Case Insensitive |