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 the
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 effective_cache_si
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 do
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
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 twic
