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

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Mitar <mmitar(at)gmail(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-08 22:39:30
Message-ID: CAKJS1f83bYRhHDuxrvCsXE_o-bsZ3dQ5wTXdjJ_MvY0z=EAo1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 8 Jan 2019 at 06:45, Mitar <mmitar(at)gmail(dot)com> wrote:
> 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.

Sounds like machine learning in the query planner. Nothing like this
exists in core, but there have been projects in the past to do this,
for example, https://axleproject.eu/2015/07/17/augmenting-the-postgresql-planner-with-machine-learning/

Perhaps there are others that have worked on similar things, however,
I don't recall any conversations on these postgresql.org mailing lists
though. Maybe it's worth trying searching the archives?

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Nicolas Karolak 2019-01-09 06:51:15 Re: multiple configurations with repmgr
Previous Message Rob Sargent 2019-01-08 21:29:07 jdbc PGCopyOutputStream close() v. endCopy()