> For example, if I have the following query:
> Select * from a where x in (select y from b where z=7)
> Then I would expect an index or hash structure to be created for b.y
> when it is first scanned and brought into the cache but I couldn't see
> it happening in the source.
> As I said, I only in
Hi Tom,
I don't believe I did run Analyze, I was under the assumption that the
statistics would have been up to date when the indexes were created.
Thanks for the quick response.
-mike
Tom Lane wrote:
> Michael Guerin <[EMAIL PROTECTED]> writes:
> >I just restored a database running on
Title: Message
I consider using PostgreSQL for a project we have in
our company and, to get a better picture of the product, I started
scanning its source code and internal documentation.
Based on what I saw (and maybe I didn't see enough)
it seems that the optimizer will always decide to re
G'day all ...
Dave asked me today about 'slow downs' on the search engines, so am
looking at the various queries generated by enabling
log_statement/log_duration, to get a feel for is something is "off" ...
and the following seems a bit weird ...
QueryA and QueryB are the same query, but against
Doug,
Yes, it does depend on the locale, you can get around this in 7.4 by
building the index with smart operators
Dave
On Thu, 2003-12-18 at 20:38, Doug McNaught wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>
> >> It appears that the optimizer only uses indexes for = clause?
> >