Re: Questions about horizontal partitioning
| От | David Lee Lambert |
|---|---|
| Тема | Re: Questions about horizontal partitioning |
| Дата | |
| Msg-id | 000a01c733f8$bb5b0940$0c0a0a0a@is215sundeep обсуждение исходный текст |
| Ответ на | Re: Questions about horizontal partitioning (Chander Ganesan <chander@otg-nc.com>) |
| Ответы |
Re: Questions about horizontal partitioning
|
| Список | pgsql-general |
Ron Johnson wrote:
On 01/08/07 20:39, Tom Lane wrote: John Sales <spelunker334@yahoo.com> writes:By doing this, I'm hoping that the query optimizer is smartenough to see that if a query comes in and requests only thesix columns (that are in the narrower table) that PostgreSQLwon't have to load the wider table into the buffer pool, andthereby actually have to only access about 10% the amount ofdisk that it presently does.No. It still has to touch the second table to confirm theexistence of rows to join to.
But if a query /requests *only* the six columns (that are in thenarrower table)/, why will the optimizer care about the other 224columns? It would. A query that uses an inner join implies that a matching entry must exist in both tables - so the join must occur, otherwise you could be returning rows that don't satisfy the join condition.
However, if the primary key is entirely within those six columns, there will have to be an index on it in both tables to enforce the primary key constraint. In that case, an inner join could be performed with an index lookup or an index scan plus hash join, for a query that didn’t use any other columns. Whether that translates into a significant I/O reduction depends on how wide and how frequently non-NULL those other columns are.
В списке pgsql-general по дате отправления: