Alvaro, Michael, > > About a month ago I mentioned that I'd find that useful. In a > > followup, Christopher Kings-Lynne brought up the idea of a GUC > > variable that could give hints about the expected row count. > > That seems pretty limited ... what happens if the query contains more > that one SRF?
Yeah, I'd see that as a pretty bad idea too. I don't want to tell the planner how many rows I expect "all functions" to return, I want to tell it how many *one particular* function will return. > Maybe issuing some sort of special call to the function (say, with > some boolean in the call info struct) on which it returns planning data; > thus the planner can call the function itself. The hard part would be > figuring out how to do it without breaking backwards compatibility with > functions that don't know how to handle that. (And how to do it in > plpgsql). Or in pl/perl, or pl/python, or plsh .... doesn't sound feasable. My solution would be a lot simpler, since we could simply populate pg_proc.proestrows with "1000" by default if not changed by the DBA. In an even better world, we could tie it to a table, saying that, for example, proestrows = my_table*0.02. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
