| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Timothy H(dot) Keitt" <keitt(at)nceas(dot)ucsb(dot)edu> |
| Cc: | Andrew McMillan <Andrew(at)catalyst(dot)net(dot)nz>, Nathan Barnett <nbarnett(at)cellularphones(dot)com>, "'Stephan Szabo'" <sszabo(at)kick(dot)com>, pgsql-general(at)postgreSQL(dot)org |
| Subject: | Re: Statistical Analysis |
| Date: | 2000-07-25 00:18:28 |
| Message-ID: | 2089.964484308@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Timothy H. Keitt" <keitt(at)nceas(dot)ucsb(dot)edu> writes:
> Oops. Just tried that; the random() call only get evaluated once.
Sigh, forgot to mention the solution. There's an undocumented function:
* bool oidrand (oid o, int4 X)-
* takes in an oid and a int4 X, and will return 'true'
* about 1/X of the time.
typically used like this:
-- select roughly 1/10 of the tuples
SELECT * FROM onek WHERE oidrand(onek.oid, 10);
This doesn't get collapsed by the overly aggressive constant-qual
recognizer because it takes a table column as input. (The function
doesn't actually *use* the OID, mind you, but the planner doesn't
know that. What a kluge... but it gets the job done.)
Note that this isn't necessarily going to fix your performance problem,
since a scan of the whole input table is still going to be required.
But if the expensive processing was somewhere downstream of that basic
scan, it should help.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Holmes | 2000-07-25 00:18:39 | Subscripts in select statements |
| Previous Message | Tom Lane | 2000-07-25 00:10:36 | Re: Statistical Analysis |