On Wed, Feb 5, 2020 at 2:28 AM Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
> There is very important reason (from my point of view): allow other
> sessions to use created index and
> so provide compatible behavior with regular tables (and with Oracle).
> So we should be able to populate index with existed GTT data.
> And ambuild will do it.
I don't understand. A global temporary table, as I understand it, is a
table for which each session sees separate contents. So you would
never need to populate it with existing data.
Besides, even if you did, how are you going to get the data for the
table? If you get the table data by flat-copying the table, then you
could copy the index files too. And you would want to, because if the
table contains a large amount of data, building indexes will be
expensive. If the index is *empty*, a file copy will not be much
cheaper than calling ambuild(), but if it's got a lot of data in it,
it will.
> Sorry, I do not understand the benefits of such optimization. It seems
> to be very rare situation when session will try to access temp table
> which was not previously filled with data. But even if it happen,
> keeping "master" copy will not safe much: we in any case have shared
> metadata and no data. Yes, with current approach, first access to GTT
> will cause creation of empty indexes. But It is just initialization of
> 1-3 pages. I do not think that delaying index initialization can be
> really useful.
You might be right, but you're misunderstanding the nature of my
concern. We probably can't allow DDL on a GTT unless no sessions are
attached. Having sessions that just read the empty GTT be considered
as "not attached" might make it easier for some users to find a time
when no backend is attached and thus DDL is possible.
> In any case, calling ambuild is the simplest and most universal
> approach, providing desired and compatible behavior.
Calling ambuild is definitely not simpler than a plain file copy. I
don't know how you can contend otherwise.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
