Re: Ad Hoc Indexes - Mailing list pgsql-hackers

From Justin
Subject Re: Ad Hoc Indexes
Date
Msg-id 47BA031E.3050406@emproshunts.com
Whole thread Raw
In response to Re: Ad Hoc Indexes  (Justin <justin@emproshunts.com>)
List pgsql-hackers
oops dam spell checker really should be rarely sorry <br /><br /> Justin wrote: <blockquote
cite="mid:47BA01D7.9010001@emproshunts.com"type="cite"></blockquote> Then why are the estimates so far off???  If
estimateswhere correct would it improve the performance that much.  <br /><br /> Vaccum is set to run automatically so
thestats stay update. <br /><br /> Total record count for the tables for all the tables put together is around 120,000
thequery returns only 458 records which is correct.  <br /><br /> If i am correct in my understanding the reason the
indeximproved the query so much is the wooper table gets hit hard because it appears in 3 separate nested queries . So
takingonly  458 records returned from the parent query times 3 for 1,375 table scans going through 21,873 records for a
totalnumber records being processed to 30,075,375  on a table with no index.  So if you look at it that way PostgreSql
didremarkably well processing the query in 18 to 20 seconds.    <br /><br /> The idea behind adhoc indexes is when one
shotqueries or rarely used queries are created that would require numerous indexes to run in a decent time can be run
ina faction of the time.  This also saves processing times across the entire system where creating indexes for the all
thepossible queries is impractical <br /><br /> This does not take away the need for index but speed up  ad-hoc queries
createdfrom a website or other business analysis tool that someone might create <br /><br /> Tom Lane wrote:
<blockquotecite="mid:1552.1203370105@sss.pgh.pa.us" type="cite"><pre wrap="">Justin <a class="moz-txt-link-rfc2396E"
href="mailto:justin@emproshunts.com"moz-do-not-send="true"><justin@emproshunts.com></a> writes: </pre><blockquote
type="cite"><prewrap="">The idea of ad hoc indexes is speed up loop scans  To prove my idea i 
 
created a sql file in PGAdmin that creates the indexes on the fly then 
runs the query then drops the indexs.   </pre></blockquote><pre wrap=""> </pre><blockquote type="cite"><pre wrap="">
withoutthe indexes it takes 18 to 19 seconds to run the query.   </pre></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">To create the index and do the query takes 400 milliseconds.   </pre></blockquote><pre
wrap="">
The example you show doesn't convince me of much of anything, because
the estimated rowcounts are so far off.  I think you're basically
dealing with an estimation failure and it's pure luck that the extra
index fixes it.
        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
              <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/faq"
moz-do-not-send="true">http://www.postgresql.org/docs/faq</a></pre></blockquote> 

pgsql-hackers by date:

Previous
From: Justin
Date:
Subject: Re: Ad Hoc Indexes
Next
From: Tom Lane
Date:
Subject: Severe regression in autoconf 2.61