Re: [PERFORM] Slow query after 9.3 to 9.6 migration

> > 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

Re: [PERFORM] why we do not create indexes on master

David, thanks a lot for the comments and for clarity. As I already responded to Andreas, I’m going to get some test data and try to investigate myself. Thought maybe I’m missing some common knowledge, that’s why asked here before taking deeper look. Regards, Val. > On Dec 27 2016, at 20:48,

[PERFORM] Fwd: [pgsql-performance] Daily digest v1.4804 (8 messages)

Hi Alex, sorry, I missed your response somehow, got it only with today’s digest. Thanks for the hint. I have basic idea how to investigate query perf issues. I thought maybe I miss some understanding of the grounds. It’ll take some time to get enough test data and I’ll try to take a look myself

[PERFORM] Slow query after 9.3 to 9.6 migration

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

Re: [PERFORM] why we do not create indexes on master

On Tue, Dec 27, 2016 at 10:38 AM, Valerii Valeev wrote: > Thank you David, > > I used same rationale to convince my colleague — it didn’t work :) > Sort of “pragmatic” person who does what seems working no matter what > happens tomorrow. > So I’m seeking for better

Re: [PERFORM] why we do not create indexes on master

Possibly some buffer caching is happening, what happens if you then remove the added index and run the query again? On 12/27/2016 10:38 AM, Valerii Valeev wrote: Thank you David, I used same rationale to convince my colleague — it didn’t work :) Sort of “pragmatic” person who does what

Re: [PERFORM] why we do not create indexes on master

Thank you David, I used same rationale to convince my colleague — it didn’t work :) Sort of “pragmatic” person who does what seems working no matter what happens tomorrow. So I’m seeking for better understanding of what's happening to have other cause to convince him. Let me break it down once

Re: [PERFORM] why we do not create indexes on master

On Tue, Dec 27, 2016 at 8:22 AM, Valerii Valeev wrote: > I have naive idea that it won’t help if index is created before the data > is there — i.e. indexes on master aren’t updated when data loaded to child > table. > ​Indexes on the master table of a partition scheme

Re: [PERFORM] why we do not create indexes on master

Valerii Valeev wrote: > Dear colleagues, > > can anyone please explain, why we do not create indexes on master? > In my case master / child design blindly follows partitioning guide https:// > www.postgresql.org/docs/9.6/static/ddl-partitioning.html. > My collaborator

[PERFORM] why we do not create indexes on master

Dear colleagues, can anyone please explain, why we do not create indexes on master? In my case master / child design blindly follows partitioning guide https://www.postgresql.org/docs/9.6/static/ddl-partitioning.html . My

Re: [PERFORM] Invalid page header in block 25561983 of relation pg_tblspc

On Tue, Dec 27, 2016 at 6:24 PM, Dinesh Chandra 12108 wrote: > Can you please suggest me how to resolve it? I think its related to block > corruption. You may want to roll in a backup, and move to a different server: https://wiki.postgresql.org/wiki/Corruption > How

[PERFORM] Invalid page header in block 25561983 of relation pg_tblspc

Dear Expert, I am getting the below error in my database. ERROR: invalid page header in block 25561983 of relation pg_tblspc/55703433/PG_9.1_201105231/55703436/113490260 Can you please suggest me how to resolve it? I think its related to block corruption. How can I find particular block in