Tom Lane wrote:
Paul Tillotson <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hardly likely, considering it's estimating only 296 rows in the subquery
output. My bet is that you've chosen a datatype whose comparisons are
not hashable (like char(n)). What is the datatype of parentid in t
Paul Tillotson <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hardly likely, considering it's estimating only 296 rows in the subquery
>> output. My bet is that you've chosen a datatype whose comparisons are
>> not hashable (like char(n)). What is the datatype of parentid in these
>> tables, an
On Wed, Jul 20, 2005 at 08:11:46PM -0400, Paul Tillotson wrote:
> Tom Lane wrote:
> >Hardly likely, considering it's estimating only 296 rows in the subquery
> >output. My bet is that you've chosen a datatype whose comparisons are
> >not hashable (like char(n)). What is the datatype of parentid i
Tom Lane wrote:
Paul Tillotson <[EMAIL PROTECTED]> writes:
For the following query, postgres is running the IN subquery over and
over again (once for each row scanned in the parent table.)
I would have expected it to run the whole query once and create a hash
which would then be probed onc
Paul Tillotson <[EMAIL PROTECTED]> writes:
> For the following query, postgres is running the IN subquery over and
> over again (once for each row scanned in the parent table.)
> I would have expected it to run the whole query once and create a hash
> which would then be probed once for every row
For the following query, postgres is running the IN subquery over and
over again (once for each row scanned in the parent table.)
I would have expected it to run the whole query once and create a hash
which would then be probed once for every row scanned in the parent
table. I assumed that i
