Re: Query Optimisation and TEXT fields

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew McMillan <Andrew(at)catalyst(dot)net(dot)nz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query Optimisation and TEXT fields
Date: 2000-08-23 03:20:26
Message-ID: 23816.967000826@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew McMillan <Andrew(at)catalyst(dot)net(dot)nz> writes:
> I am having some problems getting optimised queries when I use TEXT
> fields in records. It seems that PostgreSQL is assuming that these
> fields are 4 bytes wide so the record width calculation is wrong and
> this means that all of the dependant calculations are wrong.

4 bytes? I'd have expected 12 (see _DEFAULT_ATTRIBUTE_WIDTH_ as used
in src/backend/optimizer/path/costsize.c). While this is obviously
pretty brain-dead, I have not seen many cases in which that particular
bogosity was the limiting factor in the accuracy of the optimizer's
calculations. Usually it's the row count rather than row width that
we're hopelessly lost on :-(

At some point it might be useful for VACUUM to calculate a real
average-field-width value for varlena columns and store same in
pg_statistic. I can't get excited about it quite yet though.
If you dig into costsize.c you'll see that the estimated row width
is just a minor factor in the estimates. In particular, it has no
relevance whatever for seqscan-vs-indexscan choices.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitch Vincent 2000-08-23 03:21:52 Re: How Do You Pronounce "PostgreSQL"?
Previous Message Tom Lane 2000-08-23 03:11:16 Re: [Solved] SQL Server to PostgreSQL