Re: Can avoid list_copy in recomputeNamespacePath() conditionally?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Can avoid list_copy in recomputeNamespacePath() conditionally?
Дата
Msg-id 19685.1572705074@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Can avoid list_copy in recomputeNamespacePath() conditionally?  (amul sul <sulamul@gmail.com>)
Ответы Re: Can avoid list_copy in recomputeNamespacePath() conditionally?
Список pgsql-hackers
amul sul <sulamul@gmail.com> writes:
> I wondered can we have a shortcut somewhat similar to following POC
> in recomputeNamespacePath () when the recomputed path is the same as the
> previous baseSearchPath/activeSearchPath :
> +   /* TODO: POC */
> +   if (equal(oidlist, baseSearchPath))
> +       return;

There's an awful lot missing from that sketch; all of the remaining
steps still need to be done:

    baseCreationNamespace = firstNS;
    baseTempCreationPending = temp_missing;

    /* Mark the path valid. */
    baseSearchPathValid = true;
    namespaceUser = roleid;

    /* And make it active. */
    activeSearchPath = baseSearchPath;
    activeCreationNamespace = baseCreationNamespace;
    activeTempCreationPending = baseTempCreationPending;

    /* Clean up. */
    pfree(rawname);
    list_free(namelist);
    list_free(oidlist);

More to the point, I think the onus would be on the patch submitter
to prove that the extra complexity had some measurable benefit.
I really doubt that it would, since the list_copy is surely trivial
compared to the catalog lookup work we had to do to compute the OID
list above here.

It'd likely be more useful to see if you could reduce the number of
places where we have to invalidate the path in the first place.

            regards, tom lane



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

Предыдущее
От: Antonin Houska
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: alternative to PG_CATCH