| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Evan Martin <postgresql(at)realityexists(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Slow queries when functions are inlined |
| Date: | 2012-05-16 15:08:44 |
| Message-ID: | 26086.1337180924@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Evan Martin <postgresql(at)realityexists(dot)net> writes:
> Thanks, Tom. You mean this bit, right?
> -> Seq Scan on _test_pos (cost=0.00..10728.00 rows=1 width=4)
> Filter:
> ((('0101000020E61000000000000000001C400000000000001C40'::geography &&
> _st_expand(pos, 300000::double precision)) AND ...
> I tried to find some info on selectivity estimation functions, but only
> came up with
> http://www.postgresql.org/docs/9.1/static/xoper-optimization.html which
> talks about operators. Is there something similar for functions? Or does
> the rows estimate come from the PostGIS && operator that's used
> internally by ST_DWithin? Just trying to understand this better so I
> know what to ask on the PostGIS list.
Yeah, the _st_dwithin calls are probably also getting default estimates,
so this must be mostly on the head of the && calls. You could try
EXPLAIN ANALYZEs with just these individual filter conditions to see
which ones are far off.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Townsend | 2012-05-16 15:21:29 | Libpq question |
| Previous Message | Tom Lane | 2012-05-16 15:03:26 | Re: Query regarding Intersect clause |