On 2005-03-23, Tom Lane <[EMAIL PROTECTED]> wrote: > No, it wouldn't, because by the time you do the first FK trigger you'd > have one row/one page in the referenced table, so it'd still look like a > seqscan situation to the planner. The only way we could make that work > is to effectively disable seqscans entirely, by *always* pretending the > table size is large enough to trigger an indexscan, even when the > planner can plainly see that it's not. This is not an acceptable answer > IMHO.
I'm not yet convinced the planner is right to _ever_ choose a seqscan for FK triggers. The idea that a seqscan is faster on small tables is traditional, and it has some justification in the case where nothing is in the cache (since index scan will touch the disk twice in that case), but I'm finding that for tables of the order of 50 rows (easily fitting in one page) that index scans are as fast as or faster than seqscans for doing simple one-row lookups provided the tables are in cache. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
