Re: [HACKERS] Avoiding planning redundant backwards merges

2007-10-27 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> The idea I'm toying with is to make pathkeys_useful_for_merging() >> consider only ASC pathkeys as useful for merging --- that is, only >> pathkeys with pk_strategy = BTLessStrategyNumber. > So the case that woul

Re: [HACKERS] Avoiding planning redundant backwards merges

2007-10-27 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > The idea I'm toying with is to make pathkeys_useful_for_merging() > consider only ASC pathkeys as useful for merging --- that is, only > pathkeys with pk_strategy = BTLessStrategyNumber. This would mean that > only forward scans on ASC indexes and backward

[HACKERS] Avoiding planning redundant backwards merges

2007-10-26 Thread Tom Lane
While fooling around with the planner performance bug reported here: http://archives.postgresql.org/pgsql-bugs/2007-10/msg00173.php I noticed that even after fixing the bug, 8.3 seemed to plan this many-way join about 50% slower than 8.2 :-(. After some digging I understand the reason: 8.3 will al