I resolved the problem by eliminating the planner from the decision
making altogether, through using a (permanently) temporary table
populated by the subset of data records from an initial query generated
from the metadata, then searching only in the temp table for the actual
data records I
Thank you to David, Jeff and Tom for your responses. Tom's response has
made me rethink my question. I may have provided too much information,
in the effort to anticipate suggestions. Let me rephrase:
I have two tables, a parent (named "metadata") and a child (named
"data"). Each table
On Thu, Jun 2, 2022 at 12:32 AM Tom Lane wrote:
> Jeff Janes writes:
> > On Tue, May 31, 2022 at 4:04 PM Tim Kelly
> wrote:
> >> I do not see evidence that the nested loop is trying to reduce overhead
> >> by using the smaller set. It seems to want to scan on data first either
> >> way.
>
> >
Jeff Janes writes:
> On Tue, May 31, 2022 at 4:04 PM Tim Kelly wrote:
>> I do not see evidence that the nested loop is trying to reduce overhead
>> by using the smaller set. It seems to want to scan on data first either
>> way.
> The planner probably doesn't know which one is smaller.
There
On Tue, May 31, 2022 at 4:04 PM Tim Kelly wrote:
>
> c_db=>select count(id) from metadata where author like '%Kelly%';
>
> count
> ---
>3558
> (1 row)
>
It would be interesting to see the explain of this. We know how many rows
it found, but not how many it thinks it will find.
> I
On Wed, 1 Jun 2022 at 08:04, Tim Kelly wrote:
> -> Seq Scan on data (cost=0.00..47132.93 rows=125 width=135)
> (actual time=0.542..182952.708 rows=1167810 loops=1)
> Filter: (data ~~ '%some text%'::text)
The problem is coming from the 125 row estimate in the above
Hello Everyone,
I am stumped as to what I am doing wrong. I have two tables
metadata: parent table, 1.28m records
data: child table, 1.24m records
metadata contains descriptions of the records in data. data has two
fields of concern, the id field, which is a foreign key to an identical
