Re: Wrong estimation of rows for hash join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: Christian Schröder <cs(at)deriva(dot)de>, pgsql-general(at)postgresql(dot)org
Subject: Re: Wrong estimation of rows for hash join
Date: 2009-10-16 14:42:28
Message-ID: 6204.1255704148@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> writes:
> I'm also somewhat surprised to see an array of what appear to be
> integers be cast to bpchar[]. Did you define those coordinates(?) as
> character types? Numerical comparisons tend to be faster than string
> comparisons, which should make some difference on sequential scans.

Or, if the column can't be changed to an integer, at least consider
making it varchar not char. The funny rules about trailing blanks
make char comparison a bit slower than varchar, IIRC. They aren't
very conducive to fast hashing either ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Grzegorz Jaśkiewicz 2009-10-16 14:57:19 Re: savepoint name vs prepared transaction name
Previous Message Tom Lane 2009-10-16 14:38:52 Re: savepoint name vs prepared transaction name