Re: Skip partition tuple routing with constant partition key

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Skip partition tuple routing with constant partition key
Дата
Msg-id CAApHDvq7MBMLDjhn4C+UtNZNyZfEqZ1aFzpg+hMXZTh9WtZ3pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Skip partition tuple routing with constant partition key  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Skip partition tuple routing with constant partition key
Список pgsql-hackers
On Thu, 20 May 2021 at 01:17, Amit Langote <amitlangote09@gmail.com> wrote:
> I gave a shot to implementing your idea and ended up with the attached
> PoC patch, which does pass make check-world.

I only had a quick look at this.

+ if ((dispatch->key->strategy == PARTITION_STRATEGY_RANGE ||
+ dispatch->key->strategy == PARTITION_STRATEGY_RANGE))
+ dispatch->lastPartInfo = rri;

I think you must have meant to have one of these as PARTITION_STRATEGY_LIST?

Wondering what your thoughts are on, instead of caching the last used
ResultRelInfo from the last call to ExecFindPartition(), to instead
cached the last looked up partition index in PartitionDescData? That
way we could cache lookups between statements.  Right now your caching
is not going to help for single-row INSERTs, for example.

For multi-level partition hierarchies that would still require looping
and checking the cached value at each level.

I've not studied the code that builds and rebuilds PartitionDescData,
so there may be some reason that we shouldn't do that. I know that's
changed a bit recently with DETACH CONCURRENTLY.  However, providing
the cached index is not outside the bounds of the oids array, it
shouldn't really matter if the cached value happens to end up pointing
to some other partition. If that happens, we'll just fail the
ExecPartitionCheck() and have to look for the correct partition.

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: Skip partition tuple routing with constant partition key
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS