Re: Postgresql RDS DB Latency Chossing Hash join Plan

Hello Team, Hope everyone is doing great !!. *Background* We use PostgreSQL Version 10.6 version and heavily use PostgreSQL for our day to day activities to write and read data. We have 2 clusters running PostgreSQL engine , one cluster keeps data up to 60 days and another cluster retains da

Re: Postgresql RDS DB Latency Chossing Hash join Plan

Thanks for the feedback. On Tue, Feb 19, 2019 at 11:12 AM Michael Lewis wrote: > 1) You can increase it as much as you want but (auto)analyze will take > longer to examine the values of default_stat_target * 300 rows and compute > the most common values and the frequencies of those values. How m

Re: Postgresql RDS DB Latency Chossing Hash join Plan

1) You can increase it as much as you want but (auto)analyze will take longer to examine the values of default_stat_target * 300 rows and compute the most common values and the frequencies of those values. How much variation does you data actually have? If your data only has 50 distinct values with

Re: Postgresql RDS DB Latency Chossing Hash join Plan

On Thu, Feb 14, 2019 at 4:58 PM Michael Lewis wrote: > This is beyond my expertise except to say that if your storage is SSDs in > AWS, then you definitely want random_page_cost close to the same as > seq_page_cost (1 by default) assuming your data is likely to be in cache as > discussed in the d

Re: Postgresql RDS DB Latency Chossing Hash join Plan

This is beyond my expertise except to say that if your storage is SSDs in AWS, then you definitely want random_page_cost close to the same as seq_page_cost (1 by default) assuming your data is likely to be in cache as discussed in the documentation

Re: Postgresql RDS DB Latency Chossing Hash join Plan

On Thu, Feb 14, 2019 at 12:43 PM Michael Lewis wrote: > How many total rows in these tables? I am assuming these are partitions > and those 100 million rows got distributed. If the data difference is > significant, then you aren't guaranteed similar performance. You may want > to follow more of t

Re: Postgresql RDS DB Latency Chossing Hash join Plan

How many total rows in these tables? I am assuming these are partitions and those 100 million rows got distributed. If the data difference is significant, then you aren't guaranteed similar performance. You may want to follow more of the suggested steps on. https://wiki.postgresql.org/wiki/SlowQue

Re: Postgresql RDS DB Latency Chossing Hash join Plan

On Wed, Feb 13, 2019 at 11:38 AM Michael Lewis wrote: > I didn't see your email yesterday, sorry about that. Index scans instead > of sequential scans and nested loop instead of hash join means that you > have bad row count estimates on "Non prod Aurora RDS instance" as far as I > can figure. Hav

Re: Postgresql RDS DB Latency Chossing Hash join Plan

I didn't see your email yesterday, sorry about that. Index scans instead of sequential scans and nested loop instead of hash join means that you have bad row count estimates on "Non prod Aurora RDS instance" as far as I can figure. Have you run commands like- analyze asset_info_2019_2_part4; analy

Re: Postgresql RDS DB Latency Chossing Hash join Plan

On Tue, Feb 12, 2019 at 12:55 PM github kran wrote: > > > On Tue, Feb 12, 2019 at 12:33 PM Michael Lewis wrote: > >> Did you update the stats by running ANALYZE on the tables involved, or >> perhaps the entire database on the 'Non prod Aurora RDS instance'? Can you >> share the two execution pla

Re: Postgresql RDS DB Latency Chossing Hash join Plan

Did you update the stats by running ANALYZE on the tables involved, or perhaps the entire database on the 'Non prod Aurora RDS instance'? Can you share the two execution plans? *Michael Lewis | Software Engineer* *Entrata* *c: **619.370.8697 <619-370-8697>* On Tue, Feb 12, 2019 at 11:27 AM git

Postgresql RDS DB Latency Chossing Hash join Plan

On Tue, Feb 12, 2019 at 7:07 AM github kran wrote: > > > On Mon, Feb 11, 2019 at 6:00 PM github kran wrote: > >> >> >> On Mon, Feb 11, 2019 at 3:29 PM Michael Lewis wrote: >> >>> Are default statistics target the same on both prod and AWS? Have you >>> analyzed all tables being used in this que