I said:
> Oh, I see what it is. The initial sizing of the hash table (number of
> buckets) is done using the planner's estimate of the number of rows out
> of the subplan. In your later examples, the hash table is woefully
> overloaded and so searching it takes longer (too many items on each
> ha
On Sun, 17 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Sun, 17 Aug 2003, Tom Lane wrote:
> >> That doesn't make any sense to me --- AFAICS, only the planner pays any
> >> attention to reltuples, so it could only affect things via changing the
> >> plan. Could we s
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sun, 17 Aug 2003, Tom Lane wrote:
>> That doesn't make any sense to me --- AFAICS, only the planner pays any
>> attention to reltuples, so it could only affect things via changing the
>> plan. Could we see details?
> I've included a perl file that ge
On Sun, 17 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Basically, the first thing I noticed was that changing reltuples
> > on the pg_class row for a table affected the speed of
> > explain analyze select * from othertable where foo not in (select bar from
> > table)
On Sun, 17 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> with reltuples=1000 for pktest, query takes about 96 seconds
> >> reltuples=1, query takes about 15 seconds
> >> reltuples=10, query takes about 8 seconds
>
> > Errm, I meant in the cases where it still
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Basically, the first thing I noticed was that changing reltuples
> on the pg_class row for a table affected the speed of
> explain analyze select * from othertable where foo not in (select bar from
> table);
> even when the plan wasn't changing, seqscan +
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> with reltuples=1000 for pktest, query takes about 96 seconds
>> reltuples=1, query takes about 15 seconds
>> reltuples=10, query takes about 8 seconds
> Errm, I meant in the cases where it still chose a hashed
> subplan. Stupid cold medicine.
I
On Sat, 16 Aug 2003, Stephan Szabo wrote:
>
> I've noticed that when the stats are wrong (like
> in cases where you've loaded data but reltuples
> hasn't been updated yet) that a hashed NOT IN
> seems to take a significant time penalty. Is
> this to be expected?
>
> On a pktest table with 1 mill
I've noticed that when the stats are wrong (like
in cases where you've loaded data but reltuples
hasn't been updated yet) that a hashed NOT IN
seems to take a significant time penalty. Is
this to be expected?
On a pktest table with 1 million integers and a dual table with a single
integer and so
