| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Jules Bean <jules(at)jellybean(dot)co(dot)uk>, Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Performance on inserts |
| Date: | 2000-10-16 04:48:56 |
| Message-ID: | 21806.971671736@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> So an inner indexscan for tab1 is definitely a possible plan.
> Yes, that was my point, that a nested loop could easily be involved if
> the joined table has a restriction. Is there a TODO item here?
More like a "to investigate" --- I'm not sold on the idea that a
dynamic switch in plan types would be a win. Maybe it would be,
but...
One thing to think about is that it'd be critically dependent on having
accurate statistics. Currently, the planner only places bets on the
average behavior over a whole join. If you make a separate bet on each
scan, then you open up the risk of betting wrong every time, should
your stats be out-of-date or otherwise misleading.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | The Hermit Hacker | 2000-10-16 04:56:46 | Re: Backup, restore & pg_dump |
| Previous Message | Bruce Momjian | 2000-10-16 04:45:50 | Re: Backup, restore & pg_dump |