On Tue, Dec 27, 2016 at 3:50 PM, Flávio Henrique wrote:
> Hi there, fellow experts!
>
> I need an advice with query that became slower after 9.3 to 9.6 migration.
>
> First of all, I'm from the dev team.
>
> Before migration, we (programmers) made some modifications on query
On Thu, Jan 5, 2017 at 9:51 AM, Daniel Blanch Bataller
wrote:
> If just recreating the index now it uses it, it might mean that the index
> was bloated, that is, it grew so big that it was cheaper a seq scan.
>
> I’ve seen another case recently where postgres 9.6
Thank you for the reply. I had been trying to find that option for awhile
now.
On Fri, Jan 6, 2017 at 12:51 PM, Michael Paquier
wrote:
> On Fri, Jan 6, 2017 at 6:14 AM, Filipe Oliveira
> wrote:
> > Can you remove me from your mailing list?
>
>
On Fri, Jan 6, 2017 at 6:14 AM, Filipe Oliveira wrote:
> Can you remove me from your mailing list?
There is an unsubscribe action here:
https://www.postgresql.org/community/lists/subscribe/
--
Michael
--
Sent via pgsql-performance mailing list
Can you remove me from your mailing list?
Thanks.
On Thu, Jan 5, 2017 at 10:51 AM, Flávio Henrique wrote:
> @Merlin Moncure
>>
>> Big gains (if any) are likely due to indexing strategy.
>> I do see some suspicious casting, for example:
>> Join Filter: ((four_charlie.delta_tango)::integer =
>> (six_quebec.golf_bravo)::integer)
Hi,
If just recreating the index now it uses it, it might mean that the index was
bloated, that is, it grew so big that it was cheaper a seq scan.
I’ve seen another case recently where postgres 9.6 wasn’t using the right index
in a query, I was able to reproduce the issue crafting index
On Thu, Jan 5, 2017 at 10:51 AM, Flávio Henrique wrote:
> Replying your comment, I think they tunned the server:
> effective_cache_size = 196GB
> shared_buffers = 24GB (this shouldn't be higher?)
Probably not, although it may be a good idea to try settings either
side of
Hi all!
Sorry the delay (holidays).
Well, the most expensive sequencial scan was solved.
I asked the db team to drop the index and recreate it and guess what: now
postgresql is using it and the time dropped.
(thank you, @Gerardo Herzig!)
I think there's still room for improvement, but the
On Tue, Dec 27, 2016 at 5:50 PM, Flávio Henrique wrote:
> Hi there, fellow experts!
>
> I need an advice with query that became slower after 9.3 to 9.6 migration.
>
> First of all, I'm from the dev team.
>
> Before migration, we (programmers) made some modifications on query
On Tue, Dec 27, 2016 at 5:50 PM, Flávio Henrique wrote:
> I can see some buffers written that tells me
> that something is wrong.
Try running VACUUM FREEZE ANALYZE on all tables involved in the
query (or just run it as a superuser on the whole database). Do
*not* use the
The biggest impact on performance you can achieve is by using a materialized
view. if it’s so heavily used as you said, even 2-3 seconds in a multiuser OLTP
environment still unacceptable under my point of view. I don’t know if this is
the case but if you have 1000 users connecting at 8 am all
>
> Hi there, fellow experts!
>
>
> I need an advice with query that became slower after 9.3 to 9.6
> migration.
>
>
> First of all, I'm from the dev team.
>
>
> Before migration, we (programmers) made some modifications on query
> bring it's average time from 8s to 2-3s.
>
>
> As this
Hi there, fellow experts!
I need an advice with query that became slower after 9.3 to 9.6 migration.
First of all, I'm from the dev team.
Before migration, we (programmers) made some modifications on query bring
it's average time from 8s to 2-3s.
As this query is the most executed on our
14 matches
Mail list logo