From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to retain lesser paths at add_path()? |
Date: | 2021-10-23 20:02:40 |
Message-ID: | CAM-w4HPw=0u5ieC57Bj91bweoneSqY=ZEJWLX0C98arz-2zKjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 31 Jul 2019 at 11:45, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Jul 31, 2019 at 11:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > What you'd want to do for something like the above, I think, is to
> > have some kind of figure of merit or other special marking for paths
> > that will have some possible special advantage in later planning
> > steps. Then you can teach add_path that that's another dimension it
> > should consider, in the same way that paths with different sort orders
> > or parallizability attributes don't dominate each other.
>
> Yeah, but I have to admit that this whole design makes me kinda
> uncomfortable. Every time somebody comes up with a new figure of
> merit, it increases not only the number of paths retained but also the
> cost of comparing two paths to possibly reject one of them.
But this is a fundamental problem with having lots of possible reasons
a path might be good. Not a problem with the algorithm.
I'm imagining that you're both right. If we had some sort of way to
look at the shape of the query and make decisions early on about what
figures of merit might be relevant then we might be able to pick just
a few. Sort of like how we currently only check paths that match some
join or other query feature.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-10-23 20:42:29 | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
Previous Message | Jeff Davis | 2021-10-23 20:02:18 | Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr |