Re: Helping planner to chose sequential scan when it improves performance

2023-06-27 Thread Jeff Janes
On Sun, Jun 25, 2023 at 3:48 PM David Rowley wrote: > On Wed, 14 Jun 2023 at 07:28, Patrick O'Toole > wrote: > > Maybe we are barking up the wrong tree with the previous questions. Are > there other configuration parameters we should consider first to improve > performance in situations like

Re: Helping planner to chose sequential scan when it improves performance

2023-06-25 Thread David Rowley
On Wed, 14 Jun 2023 at 07:28, Patrick O'Toole wrote: > Maybe we are barking up the wrong tree with the previous questions. Are there > other configuration parameters we should consider first to improve > performance in situations like the one illustrated? random_page_cost and

Re: Helping planner to chose sequential scan when it improves performance

2023-06-25 Thread Jeff Janes
On Tue, Jun 13, 2023 at 3:28 PM Patrick O'Toole wrote: > run the query twice first, then... Is that a realistic way to run the test? Often forcing all the data needed for the query into memory is going to make things less realistic, not more realistic. Assuming the system has more stuff to

Re: Helping planner to chose sequential scan when it improves performance

2023-06-14 Thread Ruslan Zakirov
On Tue, Jun 13, 2023 at 10:28 PM Patrick O'Toole wrote: > Hi all, > > Questions: > >1. In Plan A, what factors are causing the planner to select a >substantially slower plan despite having recent stats about number of rows? > > Estimated overall cost. For Plan A it is ~200k. For plans

Helping planner to chose sequential scan when it improves performance

2023-06-13 Thread Patrick O'Toole
Hi all, I recently started at a new firm and have been trying to help to grok certain planner behavior. A strip-down example of the sort of join we do in the database looks like this, wherein we join two tables that have about 1 million rows: -- VACUUM (FULL, VERBOSE, ANALYZE), run the query