Re: Optimizing the same PREPAREd static query (without parameters)

From: Mitar <mmitar(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimizing the same PREPAREd static query (without parameters)
Date: 2019-01-07 17:45:35
Message-ID: CAKLmikNZHbNiUQ-oZye1jvbTk3pDt1baUg0ZO3Z=kQLxqCGR=w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi!

On Mon, Jan 7, 2019 at 12:44 AM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> If you're asking if it caches the result and foregoes scanning the
> underlying tables, then that's a "No". Else what further optimising
> did you have in mind?

For example, it could learn better statistics. In documentation [1] it
is written:

> A generic plan assumes that each value supplied to EXECUTE is one of the column's distinct values and that column values are uniformly distributed. For example, if statistics record three distinct column values, a generic plan assumes a column equality comparison will match 33% of processed rows. Column statistics also allow generic plans to accurately compute the selectivity of unique columns.

So it could learn that the values used are not distinct values, or
that column values are not uniformly distributed? And maybe decide to
change the plan? So it makes a plan, runs it, determines that the plan
was not as good as expected, I run it again, it decides to try another
plan. It is better, it decides to switch to it and keep it.

[1] https://www.postgresql.org/docs/devel/sql-prepare.html

Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Gierth 2019-01-07 19:40:47 Re: Not sure which part of the query needs optimization
Previous Message Adrian Klaver 2019-01-07 14:44:40 Re: About SSL connection