| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
| Cc: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Mnogosearch (Was: Re: website doc search is ... ) |
| Date: | 2004-01-01 19:17:50 |
| Message-ID: | 29300.1072984670@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> I don't see a difference between the two, other then time changes, but
> that could just be that runA had a server a bit more idle then runB ...
> something I'm not seeing here?
Well, the difference I was hoping for was a more accurate rows estimate
for the indexscan, which indeed we got (estimate went from 3210 to
16075, vs reality of 15533). But it didn't change the plan :-(.
Looking more closely, I see the rows estimate for the seqscan on "url"
is pretty awful too (1968 vs reality of 304811). I think it would get
better if you were doing just
AND (url.url LIKE 'http://archives.postgresql.org/%%');
without the concatenation of an empty string. Is there a reason for the
concatenation part of the expression?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2004-01-01 19:21:11 | Re: Mnogosearch (Was: Re: website doc search is ... ) |
| Previous Message | Arjen van der Meijden | 2004-01-01 19:14:49 | Re: Mnogosearch (Was: Re: website doc search is ... ) |