Re: [Proposal] Global temporary tables

2020-01-30 Thread Pavel Stehule
čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 30.01.2020 12:23, Pavel Stehule wrote: > > > Building regular index requires two kinds of lock: >> 1. You have to lock pg_class to make changes in system catalog. >> 2. You need to lock heap

Re: [Proposal] Global temporary tables

2020-01-30 Thread Konstantin Knizhnik
On 30.01.2020 12:23, Pavel Stehule wrote: Building regular index requires two kinds of lock: 1. You have to lock pg_class to make changes in system catalog. 2. You need to lock heap relation  to pervent concurrent updates while building index. GTT requires 1)  but not 2).

Re: [Proposal] Global temporary tables

2020-01-30 Thread Konstantin Knizhnik
empty indexes which everyone can use. In the case of global temporary tables, I think that we should do the same kind of copying, but at the time when the session first tries to access the table. There is some fuzziness in my mind about what exactly constitutes accessing the table - it probably

Re: [Proposal] Global temporary tables

2020-01-30 Thread Pavel Stehule
čt 30. 1. 2020 v 9:45 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 29.01.2020 20:37, Pavel Stehule wrote: > > > > st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> >> >> On 29.01.2020 20:08, Pavel Stehule wrote: >> >>

Re: [Proposal] Global temporary tables

2020-01-30 Thread Konstantin Knizhnik
On 29.01.2020 20:37, Pavel Stehule wrote: st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 29.01.2020 20:08, Pavel Stehule wrote: 2. Actually I do not propose some completely new approach. I try to

Re: [Proposal] Global temporary tables

2020-01-29 Thread Robert Haas
d then we have a brand-new, empty relation with brand-new empty indexes which everyone can use. In the case of global temporary tables, I think that we should do the same kind of copying, but at the time when the session first tries to access the table. There is some fuzziness in my mind about what

Re: [Proposal] Global temporary tables

2020-01-29 Thread Pavel Stehule
st 29. 1. 2020 v 18:21 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 29.01.2020 20:08, Pavel Stehule wrote: > > > > > 2. Actually I do not propose some completely new approach. I try to >> provide behavior with is compatible with regular tables. >> If you create

Re: [Proposal] Global temporary tables

2020-01-29 Thread Konstantin Knizhnik
On 29.01.2020 20:08, Pavel Stehule wrote: 2. Actually I do not propose some completely new approach. I try to provide behavior with is compatible with regular tables. If you create index for regular table, then it can be used in all sessions, right? I don't understand to

Re: [Proposal] Global temporary tables

2020-01-29 Thread Pavel Stehule
2. Actually I do not propose some completely new approach. I try to > provide behavior with is compatible with regular tables. > If you create index for regular table, then it can be used in all > sessions, right? > I don't understand to this point. Regular tables shares data, shares files. You

Re: [Proposal] Global temporary tables

2020-01-29 Thread Konstantin Knizhnik
the sort of thing that should worry you. At any rate, even if this somehow were or could be made safe, on-the-fly index creation is a feature that cannot and should not be combined with a patch to implement global temporary tables. Surely, it will require a lot of study and work to get the details rig

Re: [Proposal] Global temporary tables

2020-01-29 Thread Robert Haas
of thing that should worry you. At any rate, even if this somehow were or could be made safe, on-the-fly index creation is a feature that cannot and should not be combined with a patch to implement global temporary tables. Surely, it will require a lot of study and work to get the details right. An

Re: [Proposal] Global temporary tables

2020-01-29 Thread Robert Haas
On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从) wrote: >> Opinion by Pavel >> + rel->rd_islocaltemp = true; <<< if this is valid, then the name of >> field "rd_islocaltemp" is not probably best >> I renamed rd_islocaltemp > > I don't see any change? > > Rename rd_islocaltemp to rd_istemp in

Re: [Proposal] Global temporary tables

2020-01-29 Thread Robert Haas
to prohibit DDL on global temporary tables altogether. It should be fine to change things when no sessions are using the GTT. Going further and allowing changes when there are attached sessions would be nice, but I think we shouldn't try. Getting this feature committed is going to be a huge amount of

Re: [Proposal] Global temporary tables

2020-01-29 Thread 曾文旌(义从)
> 2020年1月29日 上午1:54,Pavel Stehule 写道: > > > > út 28. 1. 2020 v 18:13 odesílatel Pavel Stehule > napsal: > > > út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从) > napsal: > > >> 2020年1月29日 上午12:40,Pavel Stehule >

Re: [Proposal] Global temporary tables

2020-01-29 Thread Konstantin Knizhnik
On 27.01.2020 22:44, Pavel Stehule wrote: I don't think so compatibility with Oracle is valid point in this case. We need GTT, but the mechanism of index building should be designed for Postgres, and for users. Maybe the method proposed by you can be activated by some option like CREATE

Re: [Proposal] Global temporary tables

2020-01-28 Thread Pavel Stehule
út 28. 1. 2020 v 18:13 odesílatel Pavel Stehule napsal: > > > út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从) > napsal: > >> >> >> 2020年1月29日 上午12:40,Pavel Stehule 写道: >> >> >> >> út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从) >> napsal: >> >>> >>> >>> 2020年1月24日 上午4:47,Robert Haas 写道: >>> >>> On Sat,

Re: [Proposal] Global temporary tables

2020-01-28 Thread Pavel Stehule
út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从) napsal: > > > 2020年1月29日 上午12:40,Pavel Stehule 写道: > > > > út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从) > napsal: > >> >> >> 2020年1月24日 上午4:47,Robert Haas 写道: >> >> On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra >> wrote: >> >> I proposed just ignoring

Re: [Proposal] Global temporary tables

2020-01-28 Thread Pavel Stehule
út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从) napsal: > > > 2020年1月24日 上午4:47,Robert Haas 写道: > > On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra > wrote: > > I proposed just ignoring those new indexes because it seems much simpler > than alternative solutions that I can think of, and it's not like

Re: [Proposal] Global temporary tables

2020-01-27 Thread Pavel Stehule
po 27. 1. 2020 v 10:11 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 24.01.2020 22:39, Pavel Stehule wrote: > > I cannot to evaluate your proposal, and I am sure, so you know more about > this code. > > There is a question if we can allow to build local temp index

Re: [Proposal] Global temporary tables

2020-01-27 Thread Konstantin Knizhnik
On 25.01.2020 18:15, 曾文旌(义从) wrote: I wonder why do we need some special check for GTT here. From my point of view cleanup at startup of local storage of temp tables should be performed in the same way for local and global temp tables. After oom kill, In autovacuum, the Isolated local temp

Re: [Proposal] Global temporary tables

2020-01-27 Thread Konstantin Knizhnik
On 24.01.2020 22:39, Pavel Stehule wrote: I cannot to evaluate your proposal, and I am sure, so you know more about this code. There is a question if we can allow to build local temp index on global temp table. It is different situation. When I work with global properties personally I

Re: [Proposal] Global temporary tables

2020-01-25 Thread 曾文旌(义从)
Thank you for review patch. > 2020年1月24日 下午4:20,Konstantin Knizhnik 写道: > > > > On 23.01.2020 19:28, 曾文旌(义从) wrote: >> >> I'm trying to improve this part of the implementation in >> global_temporary_table_v7-pg13.patch >> Please check my patch and give me feedback. >> >> >> Thanks >> >>

Re: [Proposal] Global temporary tables

2020-01-24 Thread Pavel Stehule
pá 24. 1. 2020 v 14:17 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 24.01.2020 15:15, Pavel Stehule wrote: > > You will see a effect of DDL in current session (where you did the > change), all other sessions should to live without any any change do > reconnect or

Re: [Proposal] Global temporary tables

2020-01-24 Thread Konstantin Knizhnik
On 24.01.2020 15:15, Pavel Stehule wrote: You will see a effect of DDL in current session (where you did the change), all other sessions should to live without any any change do reconnect or to RESET connect Why? I found this requirement quit unnatural and contradicting to the behavior of

Re: [Proposal] Global temporary tables

2020-01-24 Thread Pavel Stehule
pá 24. 1. 2020 v 10:43 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 24.01.2020 12:09, Pavel Stehule wrote: > > > > pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> >> >> On 23.01.2020 23:47, Robert Haas wrote: >> > On

Re: [Proposal] Global temporary tables

2020-01-24 Thread Konstantin Knizhnik
On 24.01.2020 12:09, Pavel Stehule wrote: pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 23.01.2020 23:47, Robert Haas wrote: > On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote:

Re: [Proposal] Global temporary tables

2020-01-24 Thread Pavel Stehule
pá 24. 1. 2020 v 9:39 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 23.01.2020 23:47, Robert Haas wrote: > > On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra > > wrote: > >> I proposed just ignoring those new indexes because it seems much simpler > >> than alternative

Re: [Proposal] Global temporary tables

2020-01-24 Thread Konstantin Knizhnik
On 23.01.2020 23:47, Robert Haas wrote: On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra wrote: I proposed just ignoring those new indexes because it seems much simpler than alternative solutions that I can think of, and it's not like those other solutions don't have other issues. +1. For

Re: [Proposal] Global temporary tables

2020-01-24 Thread Konstantin Knizhnik
On 23.01.2020 19:28, 曾文旌(义从) wrote: I'm trying to improve this part of the implementation in global_temporary_table_v7-pg13.patch Please check my patch and give me feedback. Thanks Wenjing Below is my short review of the patch: +    /* +     * For global temp table only +     * use

Re: [Proposal] Global temporary tables

2020-01-23 Thread Robert Haas
On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra wrote: > I proposed just ignoring those new indexes because it seems much simpler > than alternative solutions that I can think of, and it's not like those > other solutions don't have other issues. +1. > For example, I've looked at the "on demand"

Re: [Proposal] Global temporary tables

2020-01-23 Thread Pavel Stehule
čt 23. 1. 2020 v 17:28 odesílatel 曾文旌(义从) napsal: > > > 2020年1月22日 下午1:29,曾文旌(义从) 写道: > > > > 2020年1月21日 下午1:43,Pavel Stehule 写道: > > Hi > > I have a free time this evening, so I will check this patch > > I have a one question > > + /* global temp table get relstats from localhash */ > + if

Re: [Proposal] Global temporary tables

2020-01-21 Thread Pavel Stehule
s 3.2MB >> and 64 tps, 6446 transaction >> >> test02.sql >> >> INSERT INTO foo SELECT random()*100, random()*1000 FROM >> generate_series(1,1000); >> ANALYZE foo; >> SELECT sum(a), sum(b) FROM foo; >> DELETE FROM foo; -- simulate disconnect &g

Re: [Proposal] Global temporary tables

2020-01-21 Thread 曾文旌(义从)
sum(a), sum(b) FROM foo; >> DELETE FROM foo; -- simulate disconnect >> >> >> after 100 sec, 1688 tps, 168830 transactions >> >> So performance is absolutely different as we expected. >> >> From my perspective, this functionality is great. >>

Re: [Proposal] Global temporary tables

2020-01-21 Thread 曾文旌(义从)
> 2020年1月21日 下午1:43,Pavel Stehule 写道: > > Hi > > I have a free time this evening, so I will check this patch > > I have a one question > > + /* global temp table get relstats from localhash */ > + if (RELATION_IS_GLOBAL_TEMP(rel)) > + { > +

Re: [Proposal] Global temporary tables

2020-01-21 Thread Pavel Stehule
erspective, this functionality is great. > > Todo: > > pg_table_size function doesn't work > > Regards > > Pavel > > >> Wenjing >> >> >> >> >> >> 2020年1月6日 上午4:06,Tomas Vondra 写道: >> >> Hi, >> >>

Re: [Proposal] Global temporary tables

2020-01-20 Thread Pavel Stehule
Hi I have a free time this evening, so I will check this patch I have a one question + /* global temp table get relstats from localhash */ + if (RELATION_IS_GLOBAL_TEMP(rel)) + { + get_gtt_relstats(RelationGetRelid(rel), + , , , + NULL, NULL); + } + else + { + /* coerce values in pg_class to

Re: [Proposal] Global temporary tables

2020-01-19 Thread Erik Rijkers
On 2020-01-19 18:04, 曾文旌(义从) wrote: 2020年1月14日 下午9:20,Pavel Stehule 写道: út 14. 1. 2020 v 14:09 odesílatel 曾文旌(义从) > napsal: [global_temporary_table_v4-pg13.patch ] Hi, This patch doesn't quiet apply for me: patching file

Re: [Proposal] Global temporary tables

2020-01-15 Thread Konstantin Knizhnik
On 15.01.2020 16:10, 曾文旌(义从) wrote: I do not see principle difference here with scenario when 50 sessions create (local) temp table, populate it with GB of data and create index for it. I think the problem is that when one session completes the creation of the index on GTT, it will

Re: [Proposal] Global temporary tables

2020-01-15 Thread 曾文旌(义从)
> 2020年1月13日 下午4:08,Konstantin Knizhnik 写道: > > > > On 12.01.2020 4:51, Tomas Vondra wrote: >> On Fri, Jan 10, 2020 at 11:47:42AM +0300, Konstantin Knizhnik wrote: >>> >>> >>> On 09.01.2020 19:48, Tomas Vondra wrote: > The most complex and challenged task is to support GTT for

Re: [Proposal] Global temporary tables

2020-01-14 Thread 曾文旌(义从)
one GTT in the entire db(include all session) . > > It's question how much GTT tables should be similar to classic tables. But > the reporting in psql should to work \dt+, \l+, \di+ Get it, I will fix it. > > > >> >> Regards >> >> Pavel >> >>

Re: [Proposal] Global temporary tables

2020-01-14 Thread 曾文旌(义从)
> 2020年1月12日 上午9:14,Tomas Vondra 写道: > > On Fri, Jan 10, 2020 at 03:24:34PM +0300, Konstantin Knizhnik wrote: >> >> >> On 09.01.2020 19:30, Tomas Vondra wrote: >> >> >>> > >> 3 Still no one commented on GTT's transaction information processing, >> they include >>

Re: [Proposal] Global temporary tables

2020-01-14 Thread Pavel Stehule
bles should be similar to classic tables. But the reporting in psql should to work \dt+, \l+, \di+ > > Regards > > Pavel > > >> Wenjing >> >> >> >> >> >> 2020年1月6日 上午4:06,Tomas Vondra 写道: >> >> Hi, >> >> I think we

Re: [Proposal] Global temporary tables

2020-01-14 Thread 曾文旌(义从)
function doesn't work Do you mean that function pg_table_size() need get the storage space used by the one GTT in the entire db(include all session) . > > Regards > > Pavel > > > Wenjing > > > > > >> 2020年1月6日 上午4:06,Tomas Vondra > <mailto:to

Re: [Proposal] Global temporary tables

2020-01-13 Thread Tomas Vondra
On Mon, Jan 13, 2020 at 09:12:38PM +0100, Julien Rouhaud wrote: On Mon, Jan 13, 2020 at 05:32:53PM +0100, Tomas Vondra wrote: On Mon, Jan 13, 2020 at 11:08:40AM +0300, Konstantin Knizhnik wrote: > >"if any code tried to access the statistics directly from the table, >rather than via the

Re: [Proposal] Global temporary tables

2020-01-13 Thread Julien Rouhaud
On Mon, Jan 13, 2020 at 05:32:53PM +0100, Tomas Vondra wrote: > On Mon, Jan 13, 2020 at 11:08:40AM +0300, Konstantin Knizhnik wrote: > > > >"if any code tried to access the statistics directly from the table, > >rather than via the caches". > > > >Currently optimizer is accessing statistic though

Re: [Proposal] Global temporary tables

2020-01-13 Thread Tomas Vondra
On Mon, Jan 13, 2020 at 11:08:40AM +0300, Konstantin Knizhnik wrote: On 12.01.2020 4:51, Tomas Vondra wrote: On Fri, Jan 10, 2020 at 11:47:42AM +0300, Konstantin Knizhnik wrote: On 09.01.2020 19:48, Tomas Vondra wrote: The most complex and challenged task is to support GTT for all kind

Re: [Proposal] Global temporary tables

2020-01-13 Thread Konstantin Knizhnik
On 12.01.2020 4:51, Tomas Vondra wrote: On Fri, Jan 10, 2020 at 11:47:42AM +0300, Konstantin Knizhnik wrote: On 09.01.2020 19:48, Tomas Vondra wrote: The most complex and challenged task is to support GTT for all kind of indexes. Unfortunately I can not proposed some good universal

Re: [Proposal] Global temporary tables

2020-01-11 Thread Tomas Vondra
On Fri, Jan 10, 2020 at 11:47:42AM +0300, Konstantin Knizhnik wrote: On 09.01.2020 19:48, Tomas Vondra wrote: The most complex and challenged task is to support GTT for all kind of indexes. Unfortunately I can not proposed some good universal solution for it. Just patching all existed

Re: [Proposal] Global temporary tables

2020-01-11 Thread Tomas Vondra
On Fri, Jan 10, 2020 at 03:24:34PM +0300, Konstantin Knizhnik wrote: On 09.01.2020 19:30, Tomas Vondra wrote: 3 Still no one commented on GTT's transaction information processing, they include 3.1 Should gtt's frozenxid need to be care? 3.2 gtt’s clog clean 3.3 How to deal with "too

Re: [Proposal] Global temporary tables

2020-01-11 Thread Pavel Stehule
i, > > I think we need to do something with having two patches aiming to add > global temporary tables: > > [1] https://commitfest.postgresql.org/26/2349/ > > [2] https://commitfest.postgresql.org/26/2233/ > > As a reviewer I have no idea which of the threads to look at -

Re: [Proposal] Global temporary tables

2020-01-10 Thread Konstantin Knizhnik
On 09.01.2020 19:30, Tomas Vondra wrote: 3 Still no one commented on GTT's transaction information processing, they include 3.1 Should gtt's frozenxid need to be care? 3.2 gtt’s clog clean 3.3 How to deal with "too old" gtt data No idea what to do about this. I wonder what is

Re: [Proposal] Global temporary tables

2020-01-10 Thread Konstantin Knizhnik
On 09.01.2020 19:48, Tomas Vondra wrote: The most complex and challenged task is to support GTT for all kind of indexes. Unfortunately I can not proposed some good universal solution for it. Just patching all existed indexes implementation seems to be the only choice. I haven't looked

Re: [Proposal] Global temporary tables

2020-01-09 Thread Tomas Vondra
On Thu, Jan 09, 2020 at 02:17:08PM +0300, Konstantin Knizhnik wrote: On 06.01.2020 8:04, 曾文旌(义从) wrote: In the previous communication 1 we agreed on the general direction 1.1 gtt use local (private) buffer 1.2 no replica access in first version 2 We feel that gtt needs to maintain

Re: [Proposal] Global temporary tables

2020-01-09 Thread Tomas Vondra
On Thu, Jan 09, 2020 at 06:07:46PM +0300, Konstantin Knizhnik wrote: On 06.01.2020 14:01, Tomas Vondra wrote: On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: In the previous communication 1 we agreed on the general direction 1.1 gtt use local (private) buffer 1.2 no replica access

Re: [Proposal] Global temporary tables

2020-01-09 Thread Konstantin Knizhnik
On 06.01.2020 14:01, Tomas Vondra wrote: On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: In the previous communication 1 we agreed on the general direction 1.1 gtt use local (private) buffer 1.2 no replica access in first version OK, good. 2 We feel that gtt needs to maintain

Re: [Proposal] Global temporary tables

2020-01-09 Thread Konstantin Knizhnik
On 06.01.2020 8:04, 曾文旌(义从) wrote: In the previous communication 1 we agreed on the general direction 1.1 gtt use local (private) buffer 1.2 no replica access in first version 2 We feel that gtt needs to maintain statistics, but there is no agreement on what it will be done. 3 Still no

Re: [Proposal] Global temporary tables

2020-01-07 Thread 曾文旌(义从)
> 2020年1月6日 下午8:17,Dean Rasheed 写道: > > On Mon, 6 Jan 2020 at 11:01, Tomas Vondra > wrote: >> >> On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: >> >>> 2 We feel that gtt needs to maintain statistics, but there is no >>> agreement on what it will be done. >>> >> >> I certainly

Re: [Proposal] Global temporary tables

2020-01-06 Thread Pavel Stehule
po 6. 1. 2020 v 13:17 odesílatel Dean Rasheed napsal: > On Mon, 6 Jan 2020 at 11:01, Tomas Vondra > wrote: > > > > On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: > > > > >2 We feel that gtt needs to maintain statistics, but there is no > > >agreement on what it will be done. > > > > >

Re: [Proposal] Global temporary tables

2020-01-06 Thread Tomas Vondra
On Mon, Jan 06, 2020 at 12:17:43PM +, Dean Rasheed wrote: On Mon, 6 Jan 2020 at 11:01, Tomas Vondra wrote: On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: >2 We feel that gtt needs to maintain statistics, but there is no >agreement on what it will be done. > I certainly agree

Re: [Proposal] Global temporary tables

2020-01-06 Thread Dean Rasheed
On Mon, 6 Jan 2020 at 11:01, Tomas Vondra wrote: > > On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: > > >2 We feel that gtt needs to maintain statistics, but there is no > >agreement on what it will be done. > > > > I certainly agree GTT needs to maintain statistics, otherwise it'll

Re: [Proposal] Global temporary tables

2020-01-06 Thread Tomas Vondra
On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote: In the previous communication 1 we agreed on the general direction 1.1 gtt use local (private) buffer 1.2 no replica access in first version OK, good. 2 We feel that gtt needs to maintain statistics, but there is no agreement on what

Re: [Proposal] Global temporary tables

2020-01-05 Thread 曾文旌(义从)
gt; > I think we need to do something with having two patches aiming to add > global temporary tables: > > [1] https://commitfest.postgresql.org/26/2349/ > > [2] https://commitfest.postgresql.org/26/2233/ > > As a reviewer I have no idea which of the threads to look at

Re: [Proposal] Global temporary tables

2020-01-05 Thread Tomas Vondra
Hi, I think we need to do something with having two patches aiming to add global temporary tables: [1] https://commitfest.postgresql.org/26/2349/ [2] https://commitfest.postgresql.org/26/2233/ As a reviewer I have no idea which of the threads to look at - certainly not without reading both

Re: Global temporary tables

2019-12-22 Thread Philippe BEAUDOIN
Hi all, I am not aware enough in the Postgres internals to give advice about the implementation. But my feeling is that there is another big interest for this feature: simplify the Oracle to PostgreSQL migration of applications that use global termporary tables. And this is quite common when

Re: Global temporary tables

2019-12-02 Thread Konstantin Knizhnik
x_relation(Oid relid, int flags, int options) if (flags & REINDEX_REL_FORCE_INDEXES_UNLOGGED) persistence = RELPERSISTENCE_UNLOGGED; else if (flags & REINDEX_REL_FORCE_INDEXES_PERMANENT) - persistence = RELPERSISTENCE_PERMANENT; + persistence = rel->rd_rel->relpersistence

Re: Global temporary tables

2019-11-30 Thread Michael Paquier
On Wed, Nov 20, 2019 at 07:32:14PM +0300, Konstantin Knizhnik wrote: > Now pg_gtt_statistic view is provided for global temp tables. Latest patch fails to apply, per Mr Robot's report. Could you please rebase and send an updated version? For now I have moved the patch to next CF, waiting on

Re: Global temporary tables

2019-11-20 Thread Konstantin Knizhnik
t options) if (flags & REINDEX_REL_FORCE_INDEXES_UNLOGGED) persistence = RELPERSISTENCE_UNLOGGED; else if (flags & REINDEX_REL_FORCE_INDEXES_PERMANENT) - persistence = RELPERSISTENCE_PERMANENT; + persistence = rel->rd_rel->relpersistence == RELPER

Re: [Proposal] Global temporary tables

2019-11-11 Thread Konstantin Knizhnik
On 08.11.2019 18:06, 曾文旌(义从) wrote: My comments for global_private_temp-4.patch Thank you very much for inspecting my patch. good side: 1 Lots of  index type on GTT. I think we need support for all kinds of indexes. 2 serial column on GTT. 3 INHERITS GTT. 4 PARTITION GTT. I didn't

Re: Global temporary tables

2019-11-11 Thread Konstantin Knizhnik
r = true; + } page = BufferGetPage(buf); PageInit(page, BufferGetPageSize(buf), sizeof(sequence_magic)); @@ -360,7 +363,8 @@ fill_seq_with_data(Relation rel, HeapTuple tuple) /* Now insert sequence tuple */ - LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE); + if (lockBuffer) + LockBuffer(buf, BUFFER_LOCK_EXC

Re: [Proposal] Global temporary tables

2019-11-08 Thread 曾文旌(义从)
My comments for global_private_temp-4.patch good side: 1 Lots of index type on GTT. I think we need support for all kinds of indexes. 2 serial column on GTT. 3 INHERITS GTT. 4 PARTITION GTT. I didn't choose to support them in the first release, but you did. Other side: 1 case: create global

Re: [Proposal] Global temporary tables

2019-11-08 Thread Konstantin Knizhnik
On 08.11.2019 10:50, 曾文旌(义从) wrote: In my opinion, it is not a good idea to trigger a btbuild with a select or DML, the cost of which depends on the amount of data in the GTT. IMHO it is better than returning error. Also index will be used only if cost of plan with index will be considered

Re: Global temporary tables

2019-11-08 Thread Konstantin Knizhnik
ffer = true; + } page = BufferGetPage(buf); PageInit(page, BufferGetPageSize(buf), sizeof(sequence_magic)); @@ -360,7 +363,8 @@ fill_seq_with_data(Relation rel, HeapTuple tuple) /* Now insert sequence tuple */ - LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE); + if (lockBuffer) + LockBuffer(buf, BUFF

Re: [Proposal] Global temporary tables

2019-11-07 Thread Konstantin Knizhnik
On 07.11.2019 12:30, 曾文旌(义从) wrote: May be the assumption is that all indexes has to be created before GTT start to be used. Yes, Currently, GTT's index is only supported and created in an empty table state, and other sessions are not using it. There has two improvements pointer: 1 Index

Re: [Proposal] Global temporary tables

2019-11-07 Thread Pavel Stehule
čt 7. 11. 2019 v 13:17 odesílatel 曾文旌(义从) napsal: > > > 2019年11月7日 下午5:40,Pavel Stehule 写道: > > > > čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) > napsal: > >> >> >> > 2019年11月7日 上午12:08,Konstantin Knizhnik 写道: >> > >> > >> > >> > On 06.11.2019 16:24, 曾文旌(义从) wrote: >> >> Dear Hackers >> >> >>

Re: [Proposal] Global temporary tables

2019-11-07 Thread 曾文旌(义从)
> 2019年11月7日 下午5:40,Pavel Stehule 写道: > > > > čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) > napsal: > > > > 2019年11月7日 上午12:08,Konstantin Knizhnik > > 写道: > > > > > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: > >> Dear

Re: [Proposal] Global temporary tables

2019-11-07 Thread Pavel Stehule
čt 7. 11. 2019 v 10:30 odesílatel 曾文旌(义从) napsal: > > > > 2019年11月7日 上午12:08,Konstantin Knizhnik 写道: > > > > > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: > >> Dear Hackers > >> > >> > >> I attached the patch of GTT implementationI base on PG12. > >> The GTT design came from my first email. > >>

Re: [Proposal] Global temporary tables

2019-11-07 Thread 曾文旌(义从)
> 2019年11月7日 上午12:08,Konstantin Knizhnik 写道: > > > > On 06.11.2019 16:24, 曾文旌(义从) wrote: >> Dear Hackers >> >> >> I attached the patch of GTT implementationI base on PG12. >> The GTT design came from my first email. >> Some limitations in patch will be eliminated in later versions. >> >>

Re: [Proposal] Global temporary tables

2019-11-06 Thread Konstantin Knizhnik
trel = table_open(toastrelid, lockmode); table_relation_nontransactional_truncate(toastrel); - RelationTruncateIndexes(toastrel); + RelationTruncateIndexes(toastrel, lockmode); /* keep the lock... */ table_close(toastrel, NoLock); } + + if (RELATION_IS_GLOBAL_TEMP(rel)) + up_

Re: [Proposal] Global temporary tables

2019-11-02 Thread Pavel Stehule
And pg_catalog.pg_statistics_gtt() is set returning functions? > yes I afraid that it is not acceptable solution from performance point of view: > pg_statictic table is accessed by keys (,,) > I don't think so it is problem. The any component, that needs to use fast access can use some special

Re: [Proposal] Global temporary tables

2019-11-02 Thread Julien Rouhaud
On Sat, Nov 2, 2019 at 4:09 PM Konstantin Knizhnik wrote: > > On 02.11.2019 10:19, Julien Rouhaud wrote: > > On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule > > wrote: > >> pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik > >> napsal: > >>> On 01.11.2019 18:26, Robert Haas wrote: > On

Re: [Proposal] Global temporary tables

2019-11-02 Thread Konstantin Knizhnik
On 02.11.2019 8:30, Pavel Stehule wrote: pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> napsal: On 01.11.2019 18:26, Robert Haas wrote: > On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik > mailto:k.knizh...@postgrespro.ru>>

Re: [Proposal] Global temporary tables

2019-11-02 Thread Konstantin Knizhnik
On 02.11.2019 10:19, Julien Rouhaud wrote: On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule wrote: pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik napsal: On 01.11.2019 18:26, Robert Haas wrote: On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik wrote: It seems to me that I have

Re: [Proposal] Global temporary tables

2019-11-02 Thread Julien Rouhaud
On Sat, Nov 2, 2019 at 8:23 AM Pavel Stehule wrote: > > so 2. 11. 2019 v 8:18 odesílatel Julien Rouhaud napsal: >> >> On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule wrote: >> > >> > pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik >> > napsal: >> >> >> >> On 01.11.2019 18:26, Robert Haas

Re: [Proposal] Global temporary tables

2019-11-02 Thread Pavel Stehule
so 2. 11. 2019 v 8:23 odesílatel Pavel Stehule napsal: > > > so 2. 11. 2019 v 8:18 odesílatel Julien Rouhaud > napsal: > >> On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule >> wrote: >> > >> > pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik < >> k.knizh...@postgrespro.ru> napsal: >> >> >> >>

Re: [Proposal] Global temporary tables

2019-11-02 Thread Pavel Stehule
so 2. 11. 2019 v 8:18 odesílatel Julien Rouhaud napsal: > On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule > wrote: > > > > pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > >> > >> On 01.11.2019 18:26, Robert Haas wrote: > >> > On Fri, Nov 1, 2019 at

Re: [Proposal] Global temporary tables

2019-11-02 Thread Julien Rouhaud
On Sat, Nov 2, 2019 at 6:31 AM Pavel Stehule wrote: > > pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik > napsal: >> >> On 01.11.2019 18:26, Robert Haas wrote: >> > On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik >> > wrote: >> >> It seems to me that I have found quite elegant

Re: [Proposal] Global temporary tables

2019-11-01 Thread Pavel Stehule
pá 1. 11. 2019 v 17:09 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal: > > > On 01.11.2019 18:26, Robert Haas wrote: > > On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik > > wrote: > >> It seems to me that I have found quite elegant solution for per-backend > statistic for

Re: [Proposal] Global temporary tables

2019-11-01 Thread Konstantin Knizhnik
On 01.11.2019 18:26, Robert Haas wrote: On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik wrote: It seems to me that I have found quite elegant solution for per-backend statistic for GTT: I just inserting it in backend's catalog cache, but not in pg_statistic table itself. To do it I

Re: [Proposal] Global temporary tables

2019-11-01 Thread Robert Haas
On Fri, Nov 1, 2019 at 11:15 AM Konstantin Knizhnik wrote: > It seems to me that I have found quite elegant solution for per-backend > statistic for GTT: I just inserting it in backend's catalog cache, but not in > pg_statistic table itself. > To do it I have to add

Re: [Proposal] Global temporary tables

2019-11-01 Thread Konstantin Knizhnik
kBuffer) + UnlockReleaseBuffer(buf); } /* @@ -502,7 +507,7 @@ AlterSequence(ParseState *pstate, AlterSeqStmt *stmt) /* * Insert the modified tuple into the new storage file. */ - fill_seq_with_data(seqrel, newdatatuple); + fill_seq_with_data(seqrel, newdatatuple, InvalidBuffer); }

Re: [Proposal] Global temporary tables

2019-10-29 Thread Konstantin Knizhnik
ate *pstate, AlterSeqStmt *stmt) /* * Insert the modified tuple into the new storage file. */ - fill_seq_with_data(seqrel, newdatatuple); + fill_seq_with_data(seqrel, newdatatuple, InvalidBuffer); } /* process OWNED BY if given */ @@ -1178,6 +1183,17 @@ read_seq_tuple(Relation r

Re: [Proposal] Global temporary tables

2019-10-28 Thread Robert Haas
On Mon, Oct 28, 2019 at 9:37 AM Konstantin Knizhnik wrote: > Sorry, but both statements are not true. Well, I think they are true. > I am not sure how vital is lack of aborts for transactions working with > GTT at replica. > Some people said that there is no sense in aborts of read-only >

Re: [Proposal] Global temporary tables

2019-10-28 Thread Robert Haas
On Mon, Oct 28, 2019 at 9:48 AM Konstantin Knizhnik wrote: > Logically it may be good decision. But piratically support of parallel > access to GTT requires just accessing their data through shared buffer. > But in case of local temp tables we need also need to some how share > table's metadata

Re: [Proposal] Global temporary tables

2019-10-28 Thread Konstantin Knizhnik
temp tables, not separate solutions for each. Sorry, may be I do not not understand you. It seems to me that there is only one thing preventing usage of temporary tables in parallel plans: private buffers. If global temporary tables are accessed as normal tables though shared buffers then them can

Re: [Proposal] Global temporary tables

2019-10-28 Thread Konstantin Knizhnik
TransactionStateData *TransactionState; @@ -286,6 +287,12 @@ typedef struct XactCallbackItem static XactCallbackItem *Xact_callbacks = NULL; +static TransactionId replicaTransIdCount = FirstNormalTransactionId; +static TransactionId replicaTopTransId; +static Bitmapset*replicaAbortedXids; + +bool

Re: [Proposal] Global temporary tables

2019-10-28 Thread Robert Haas
tually support > > temp relations for parallel query, we're going to want a solution that > > is shared between regular temp tables and global temp tables, not > > separate solutions for each. > > Sorry, may be I do not not understand you. > It seems to me that there is onl

Re: [Proposal] Global temporary tables

2019-10-28 Thread Robert Haas
On Fri, Oct 25, 2019 at 11:14 AM Pavel Stehule wrote: >> > Access to GTT at replica: >> > 1. Access is prohibited (as for original temp tables). No changes at all. >> > 2. Tuples of temp tables are marked with forzen XID. Minimal changes, >> > rollbacks are not possible. >> > 3. Providing

Re: [Proposal] Global temporary tables

2019-10-28 Thread 曾文旌(义从)
support >> temp relations for parallel query, we're going to want a solution that >> is shared between regular temp tables and global temp tables, not >> separate solutions for each. > > Sorry, may be I do not not understand you. > It seems to me that there is only one thin

Re: [Proposal] Global temporary tables

2019-10-25 Thread Pavel Stehule
> > > >> So except the limitation mentioned above (which I do not consider as > critical) there is only one problem which was not addressed: maintaining > statistics for GTT. > >> If all of the following conditions are true: > >> > >> 1) GTT are used in joins > >> 2) There are indexes defined for

Re: [Proposal] Global temporary tables

2019-10-25 Thread Konstantin Knizhnik
to me that there is only one thing preventing usage of temporary tables in parallel plans: private buffers. If global temporary tables are accessed as normal tables though shared buffers then them can be used in parallel queries and no extra support is required for it. At least I have checked

<    1   2   3   4   >