Re: Functional dependencies and GROUP BY
От | Alex Hunsaker |
---|---|
Тема | Re: Functional dependencies and GROUP BY |
Дата | |
Msg-id | AANLkTinLdcErLQFV5XveMR589idSjdCV=cWu16T_Z_hB@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Functional dependencies and GROUP BY (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Functional dependencies and GROUP BY
Re: Functional dependencies and GROUP BY |
Список | pgsql-hackers |
On Sun, Jul 18, 2010 at 02:40, Peter Eisentraut <peter_e@gmx.net> wrote: > On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote: >> So I would expect the more indexes you >> had or group by items to slow it down. Not so much the number of >> columns. Right? > > At the outer level (which is not visible in this patch) it loops over > all columns in the select list, and then it looks up the indexes each > time. So the concern was that if the select list was * with a wide > table, looking up the indexes each time would be slow. Thanks for the explanation. >> Anyhow it sounds like I should try it on top of the other patch and >> see if it works. I assume it might still need some fixups to work >> with that other patch? Or do you expect it to just work? > > There is some work necessary to integrate the two. I just read that patch is getting pushed till at least the next commit fest: http://archives.postgresql.org/pgsql-hackers/2010-07/msg01219.php Should we push this patch back to? Alternatively we could make it work with just primary keys until the other patch gets in. I think that makes sense, find that attached. Thoughts? Note I axed the index not null attribute checking, I have not thought to deeply about it other than if its a primary key it cant have non null attributes.... Right? I may have missed something subtle hence the heads up.
Вложения
В списке pgsql-hackers по дате отправления: