| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | marcin mank <marcin(dot)mank(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: per table random-page-cost? |
| Date: | 2009-10-19 22:45:33 |
| Message-ID: | 4ADCEC0D.40808@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
marcin mank wrote:
>> I've been thinking about this a bit, too. I've been wondering if it
>> might make sense to have a "random_page_cost" and "seq_page_cost"
>> setting for each TABLESPACE, to compensate for the fact that different
>> media might be faster or slower, and a percent-cached setting for each
>> table over top of that.
>>
>>
>
> I thought about making it per-table, but realistically I think most
> people don`t use tablespaces now. I would not want to be telling
> people "to be able to hint the planner to (not) index-scan the table,
> You must move it to a separate tablespace".
>
This is just plain wrong, in my experience. *Every* large installation I
deal with uses tablespaces.
This proposal is just "hints by the back door", ISTM. As Tom says, there
is a justification for having it on tablespaces but not on individual
tables.
If you want to argue for full blown planner hints, that's a whole other
story. Have you read the previous debates on the subject?
cheers
| From | Date | Subject | |
|---|---|---|---|
| Next Message | marcin mank | 2009-10-19 23:04:04 | Re: per table random-page-cost? |
| Previous Message | Tom Lane | 2009-10-19 22:45:03 | Re: Could postgres be much cleaner if a future release skipped backward compatibility? |