Re: Using ctid column changes plan drastically

От: Thomas Kellerer
Тема: Re: Using ctid column changes plan drastically
Дата: ,
Msg-id: jumim1$nq7$1@dough.gmane.org
(см: обсуждение, исходный текст)
Ответ на: Re: Using ctid column changes plan drastically  (Tom Lane)
Ответы: Re: Using ctid column changes plan drastically  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Using ctid column changes plan drastically  (Thomas Kellerer, )
 Re: Using ctid column changes plan drastically  (Tom Lane, )
  Re: Using ctid column changes plan drastically  (Thomas Kellerer, )
   Re: Using ctid column changes plan drastically  (Tom Lane, )
    Re: Using ctid column changes plan drastically  (Thomas Kellerer, )
     Re: Using ctid column changes plan drastically  (Tom Lane, )
      Re: Using ctid column changes plan drastically  (Thomas Kellerer, )
       Re: Using ctid column changes plan drastically  ("Kevin Grittner", )

Tom Lane wrote on 24.07.2012 17:55:
> Joins on tid columns just aren't supported very well at the moment.
> Partly that's from lack of round tuits, and partly it's because it
> doesn't seem all that wise to encourage people to use them.  There
> are gotchas if any of the rows receive concurrent updates.

Thanks for the clarification. I will keep that in mind.

> FWIW, it might be helpful to cast this as a NOT EXISTS rather than
> NOT IN subquery.

Hmm. How would you change that into an NOT EXISTS clause (so that one of the duplicates remains)
Everything I come up with is in fact slower than the NOT IN solution.

Regards
Thomas




В списке pgsql-performance по дате сообщения:

От: Claudio Freire
Дата:
Сообщение: Re: Linux memory zone reclaim
От: Aleksei Arefjev
Дата:
Сообщение: Re: transactions start time