On 01.07.2020 12:30, Daniel Gustafsson wrote:
On 24 Mar 2020, at 17:24, Konstantin Knizhnik wrote:
Rebased version of the patch is attached.
And this patch also fails to apply now, can you please submit a new version?
Marking the entry as Waiting on Author in the meantime.
cheers ./daniel
On 23.06.2020 10:15, James Sewell wrote:
Using multithreading in bgworker is possible if you do not use any
Postgres runtime inside thread procedures or do it in exclusive
critical
section.
It is not so convenient but possible. The most difficult thing
from my
point
On 23.06.2020 06:38, Tom Lane wrote:
James Sewell writes:
I was talking about PostgreSQL and threading on IRC the other day - which I
know is a frowned upon topic - and just wanted to frame the same questions
here and hopefully get a discussion going.
I think the short answer about threadin
On 26.05.2020 04:47, Tomas Vondra wrote:
On Mon, May 25, 2020 at 09:21:26PM -0400, Bruce Momjian wrote:
On Mon, May 25, 2020 at 07:53:40PM -0500, Bert Scalzo wrote:
I am reposting this from a few months back (see below). I am not
trying to be a
pest, just very motivated. I really think this
On 20.05.2020 10:36, Noah Misch wrote:
On Wed, May 20, 2020 at 10:23:37AM +0300, Konstantin Knizhnik wrote:
On 20.05.2020 06:05, Noah Misch wrote:
On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:
Definition of pg_atomic_compare_exchange_u64 requires alignment of expected
On 20.05.2020 08:10, Andres Freund wrote:
Hi,
On May 19, 2020 8:05:00 PM PDT, Noah Misch wrote:
On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:
Definition of pg_atomic_compare_exchange_u64 requires alignment of
expected
pointer on 8-byte boundary
On 20.05.2020 06:05, Noah Misch wrote:
On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:
Definition of pg_atomic_compare_exchange_u64 requires alignment of expected
pointer on 8-byte boundary.
pg_atomic_compare_exchange_u64(volatile pg_atomic_uint64 *ptr
Definition of pg_atomic_compare_exchange_u64 requires alignment of
expected pointer on 8-byte boundary.
pg_atomic_compare_exchange_u64(volatile pg_atomic_uint64 *ptr,
uint64 *expected, uint64 newval)
{
#ifndef PG_HAVE_ATOMIC_U64_SIMULATION
AssertPointerAlignmen
On 03.04.2020 15:29, Robert Haas wrote:
Hi,
Suppose that the server is executing a lengthy query, and the client
breaks the connection. The operating system will be aware that the
connection is no more, but PostgreSQL doesn't notice, because it's not
try to read from or write to the socket. I
On 25.03.2020 20:04, Rafia Sabih wrote:
Also, there is no description about any of the functions here,
wouldn’t hurt having some more comments there.
Attached please find new version of the patch with more comments and
descriptions added.
--
Konstantin Knizhnik
Postgres Professional
y limit on the number of columns for which this will
work, or should there be any such limit...?
Right now there is limit for maximal number of columns used in extended
statistic: 8 columns.
But in practice I rarely see join predicates involving more than 3 columns.
--
Konstantin Knizhnik
Postgr
idn't check
versions below 8.4 though.
Thanks
Richard
I can propose the following patch for the problem.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index
On 25.03.2020 16:00, David Steele wrote:
On 3/25/20 6:57 AM, Konstantin Knizhnik wrote:
On 24.03.2020 20:12, David Steele wrote:
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer
On 24.03.2020 20:12, David Steele wrote:
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join selectivity.
This patch fixes race condition while
vs. 1881
seconds.
Looks like it was mostly limited by time of writing data to the disk.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/access/transam/generic_xlog.c b/src/backend/access/transam/generic_xlog.c
index
Hi David,
On 24.03.2020 16:26, David Steele wrote:
Hi Konstantin,
On 11/14/19 2:06 AM, Konstantin Knizhnik wrote:
Attached please find rebased patch with this bug fixed.
This patch no longer applies: http://cfbot.cputube.org/patch_27_2067.log
CF entry has been updated to Waiting on Author
n and
postgres_fdw establish its own session where content of the table is empty.
But if you insert some data in f_gtt1, then you will be able to select
this data from it because of connection cache in postgres_fdw.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
h enabled JIT.
And providing vectorized version of ExecInterpExpr will not help to
increase speed (according to profile time is spent in other places).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
) ▒ - 17.46%
Vadvance_transition_function (inlined) ▒ + 11.95% vfloat8_accum ▒ +
4.74% vfloat8pl ▒ 0.75% vint8inc_any ▒ + 2.77% ExecProject (inlined)
It is strange that I am not seeing lookup_hash_entry in profile in my case.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
On 25.02.2020 19:40, Konstantin Knizhnik wrote:
I have ported vectorize_engine for zedstore (vertical table AM).
Results of TPCH-10G/Q1 are the following:
par.workers
PG9_6
vectorize=off
PG9_6
vectorize=on
master
vectorize=off
jit=on
master
vectorize=off
jit
attributes from foo although we need just "x".
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
/*-
*
* zedstoream_handler.c
* ZedStore table access m
r on github. Please accepted and
try again.
I think non collaborator could also open pull requests.
On Mon, Feb 24, 2020 at 8:02 PM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On 24.02.2020 05:08, Hubert Zhang wrote:
Hi
On Sat,
On 24.02.2020 05:08, Hubert Zhang wrote:
Hi
On Sat, Feb 22, 2020 at 12:58 AM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On 12.02.2020 13:12, Hubert Zhang wrote:
On Tue, Feb 11, 2020 at 1:20 AM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru&g
On 12.02.2020 13:12, Hubert Zhang wrote:
On Tue, Feb 11, 2020 at 1:20 AM Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
So looks like PG-13 provides significant advantages in OLAP
queries comparing with 9.6!
Definitely it doesn't mean that vectorized
een ported, I expect that it should provide comparable improvement
of performance.
But in any case I think that vectorized executor makes sense only been
combine with columnar store.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Sorry, small typo in the last patch.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/pg_prewarm/pg_prewarm.c b/contrib/pg_prewarm/pg_prewarm.c
index 33e2d28..93059ef 100644
--- a/contrib/pg_prewarm/pg_prewarm.c
+++ b
On 07.02.2020 21:37, Pavel Stehule wrote:
What when session 2 has active transaction? Then to be correct, you
should to wait with index creation to end of transaction.
Session1:
postgres=# create unique index on gtt(x);
CREATE INDEX
Sessin2:
postgres=# explain select *
Fix GTT index initialization.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/pg_prewarm/pg_prewarm.c b/contrib/pg_prewarm/pg_prewarm.c
index 33e2d28..93059ef 100644
--- a/contrib/pg_prewarm/pg_prewarm.c
+++ b/contrib
On 07.02.2020 18:15, Robert Haas wrote:
On Wed, Feb 5, 2020 at 10:48 AM Konstantin Knizhnik
wrote:
My answer is - yes.
Just because:
- Such behavior is compatible with regular tables. So it will not
confuse users and doesn't require some complex explanations.
- It is compatible with O
On 05.02.2020 17:10, Robert Haas wrote:
On Wed, Feb 5, 2020 at 2:28 AM Konstantin Knizhnik
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
On 05.02.2020 00:38, Robert Haas wrote:
My guess it that the right time to do this work is just after we
acquire locks, at the end of parse analysis. I think trying to do it
during execution is too late, since the planner looks at indexes, and
trying to do it in the planner instead of before
On 04.02.2020 18:01, 曾文旌(义从) wrote:
Yes, exactly.
But it is still not clear to me why do we need some special handling
for GTT?
Shared memory is reinitialized and storage of temporary tables is
removed.
It is true for both local and global temp tables.
Of course not. The local temp table
/2349/
New version of the patch with new method of GTT index construction is
attached.
Now GTT indexes are checked before query execution and are initialized
using AM build method.
So now GTT is supported for all indexes, including custom indexes.
--
Konstantin Knizhnik
Postgres Professional
On 01.02.2020 19:14, 曾文旌(义从) wrote:
2020年1月27日 下午5:38，Konstantin Knizhnik <mailto:k.knizh...@postgrespro.ru>> 写道：
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
tabl
uery.
Do you seem some problems with such approach?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
actually this function continue traversal until end of the table
even if tuple was found.
I wonder if break; should be added to the end of for loop.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 30.01.2020 12:52, Pavel Stehule wrote:
čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik
mailto: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_cl
depends only on private data and can not be somehow affected by other
backends (taken in account that we preserve locking policy of regular
tables).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 29.01.2020 21:16, Robert Haas wrote:
On Wed, Jan 29, 2020 at 10:30 AM Konstantin Knizhnik
wrote:
I think that the idea of calling ambuild() on the fly is not going to
work, because, again, I don't think that calling that from random
places in the code is safe.
It is not a random
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
port it for GTT.
Actually "not more complex" in this case means "no extra efforts are
needed".
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 29.01.2020 17:47, Robert Haas wrote:
On Wed, Jan 29, 2020 at 3:13 AM Konstantin Knizhnik
wrote:
But I heard only two arguments:
1. Concurrent building of indexes by all backends may consume much memory
(n_backends * maintenance_work_mem) and consume a lot of disk/CPU resources.
2. GTT
can be changed...
Sorry, but I do not consider proposals to create indexes locally for
each session (i.e. global tables but private indexes) or use some
special complicated SQL syntax constructions like
CREATE INDEX IMMEDIATELY FOR ALL SESSION as some real alternatives which
have to be discussed.
expected to live long time.
Certainly it is possible to imagine situation when session use GTT to
store some local data which is valid during all session life time (which
can be large enough).
But I am not sure that it is popular scenario.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
is to make it compatible with normal tables.
And do not forget about compatibility with Oracle. Simplifying of
porting existed applications from Oracle to Postgres may be the
main motivation of adding GTT to Postgres. And making them incompatible
with Oracle will be very strange.
--
Konstantin
nitialize index and populates it with data.
So the solution proposed for me is most natural, convenient and simplest
solution at the same time. And compatible with Oracle.
Regards
Pavel
--
Konstantin Knizhnik
Postgres Professional:http://www.postgrespro.com
The Russian P
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
ing table schema.
My current solution is to allow creation/droping index on GTT and
dropping table itself, while prohibit alter schema at all for GTT.
Wenjing's approach is to prohibit any DDL if GTT is used by more than
one backend.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
acumm will produce this
warnings (which will ton be visible by end user and only appended to the
log).
And at some moment of time wrap around happen and if there still some
old active GTT, we will get incorrect results.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
sting maintenance_work_mem, so this solution is more flexible.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 14.01.2020 17:40, Tom Lane wrote:
Konstantin Knizhnik writes:
Right now changing policies (create/alter policy statements) requires
exclusive lock of target table:
Yup.
I wonder why do we really need exclusive lock here?
Because it affects the behavior of a SELECT.
May be I missed
in pg_policy table and perform
RLS checks according to old policies. Once transaction is committed,
everybody will switch to new policies.
I wonder if we it is possible to replace AccessExclusiveLock with
AccessSharedLock in RangeVarGetRelidExtended in CreatePolicy and
AlterPolicy?
--
Konstan
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
o me that
nobody complains about it.
We discuss many issues related with temp tables (statistic, parallel
queries,...) which seems to be less critical.
But this problem is not specific to GTT - it can be reproduced with
normal (local) temp tables.
This is why I wonder why do we need to solve
if you can point me on what is
wrong with this approach, I will think about alternative solution.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
here?
The same problem takes place for normal (local) temp tables, doesn't it?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
porary tables is overkill from my point of view.
I do not understand why do we need to maintain hash with some extra
information for GTT in backends memory (as it was done in Wenjing patch).
Also idea to use create extension for accessing this information seems
to be dubious.
--
Kon
).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/auto_explain/auto_explain.c b/contrib/auto_explain/auto_explain.c
index a9536c2..3f9d6ef 100644
--- a/contrib/auto_explain/auto_explain.c
+++ b/contrib/auto_explain/auto_explain.c
d by two transactions both of
which were started before us and committed during table traversal by
transaction with "read uncommitted" policy. Certainly "read uncommitted"
means that we are ready to get inconsistent results, but is it really
acceptable to multiple versions
walWritten field.
As far as at 64-bit systems, pg_atomic_write_u64and pg_atomic_read_u64
are translated to ordinary memory access, them should not have some
negative
impact on performance.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backe
On 06.12.2019 19:52, Konstantin Knizhnik wrote:
On 06.12.2019 18:53, Robert Haas wrote:
On Thu, Nov 28, 2019 at 2:08 AM Konstantin Knizhnik
wrote:
calls float4_accum for each row of T, the same query in VOPS will call
vops_float4_avg_accumulate for each tile which contains 64 elements
On 06.12.2019 18:53, Robert Haas wrote:
On Thu, Nov 28, 2019 at 2:08 AM Konstantin Knizhnik
wrote:
calls float4_accum for each row of T, the same query in VOPS will call
vops_float4_avg_accumulate for each tile which contains 64 elements.
So vops_float4_avg_accumulate is called 64 times
On 06.12.2019 4:57, Michael Paquier wrote:
On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote:
Concerning keeping PGPROC size as small as possible, I agree that it is
reasonable argument.
But even now it is very large (816 bytes) and adding extra 8 bytes will
increase it on
that race conditions here are so critical.
Right now pg_stat_activity also accessing PGPROC to obtain wait event
information and also not taking any locks.
So it can wrongly report backend status. But I never heard that somebody
complains about it.
--
Konstantin Knizhnik
Postgres Profession
Hi,
Thank you for your replay and explanations.
My comments are inside.
On 04.12.2019 22:43, Andres Freund wrote:
Hi,
On 2019-11-25 18:09:29 +0300, Konstantin Knizhnik wrote:
I wonder why even at this query, which seems to be ideal use case for JIT,
we get such modest improvement?
I think
or parallel search so if we want to provide
parallel execution for vectorized operations we need also to substitute
this nodes with
custom nodes.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
.
Will fix it.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
h from my point of view is adding 8
bytes to PGPROC.
But there are already so many fields in this structure
(sizeof(PGPROC)=816), that adding yet another 8 bytes should not be
noticeable.
Comments are welcome.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russia
rized scan can be combined with parallel execution (it is
already supported in9.6, isn't it?)
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 01.12.2019 6:26, Michael Paquier wrote:
On Thu, Sep 26, 2019 at 10:23:38AM +0300, Konstantin Knizhnik wrote:
Sorry,
New version of the patch with corrected expected output for rules test is
attached.
It looks like the documentation is failing to build. Could you fix
that? There may be
On 01.12.2019 4:56, Michael Paquier wrote:
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
think about format of storing data in
VectorTupleTableSlot? Should it be array of Datum? Or we need to
represent vector in more low level format (for example
as array of floats for real4 type)?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
y checks
I want to exclude this overhead and reach almost the same speed as VOPS.
But it doesn't happen.
Konstantin Knizhnik <mailto:k.knizh...@postgrespro.ru>> 于2019年11月28日周四 下午3:08写道：
On 27.11.2019 19:05, Tomas Vondra wrote:
> On Wed, Nov 27, 2019 at 06:38:
On 27.11.2019 19:05, Tomas Vondra wrote:
On Wed, Nov 27, 2019 at 06:38:45PM +0300, Konstantin Knizhnik wrote:
On 25.11.2019 18:24, Merlin Moncure wrote:
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
JIT was not able to significantly (times) increase speed on Q1 query
On 25.11.2019 18:24, Merlin Moncure wrote:
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
JIT was not able to significantly (times) increase speed on Q1 query?
Experiment with VOPS shows that used aggregation algorithm itself is not
a bottleneck.
Profile also give no answer for
On 27.11.2019 15:12, Rafia Sabih wrote:
On Wed, 27 Nov 2019 at 12:33, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Hi hackers,
I wonder how it is possible to prohibit parallel scan for the
external
storage accessed through tableam?
For exampl
local to the backend)?
Thanks in advance,
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
VOPS shows that used aggregation algorithm itself is not
a bottleneck.
Profile also give no answer for this question.
Any ideas?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
optimization
Postgres can produce incorrect result in case of incorrectly specidied
immutable or stable qualifiers.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ons.
Notes, comments?
I think that even current model with "volatile", "immutable" and
"stable" is complex enough.
Adding more qualifiers will make it even more obscure and error-prone.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I've set the CF entry to "Waiting on Author" pending a new patch
that does it like that.
With contain_mutable_functions the patch becomes trivial.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/pl/plpgsq
Now pg_gtt_statistic view is provided for global temp tables.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index ae7b729..485c068 100644
--- a/src/backend/access
_statistic, then reported error is "cannot cast type record to
pg_statistic".
So the only possible way I found is to create extension and define
function in this extension.
I wonder if there is some better solution?
Thanks in advance,
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
with
"wal_receiver_start_condition" GUC added (preserving by default original
behavior).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f837703..bf4e9d4 100644
--- a/doc/src/sgml/co
not imagine that unlike standard itoa it accepts int16 parameter
instead of int).
Attached please find rebased patch with this bug fixed.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/spi/refint.c b/contrib/spi/ref
Hi
On 12.11.2019 10:50, ideriha.take...@fujitsu.com wrote:
Hi.
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
New version of builtin connection pooler fixing handling messages of extended
protocol.
Here are things I've noticed.
1. Is adding guc to postgresql.conf.s
that it "proves nothing" if extension can put stuff in
pg_catalog.
I can replace it with comparison with FirstGenbkiObjectId.
But all this makes sense only if using contain_mutable_function() is not
acceptable.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
nciple, I have also implemented special visibility rules for GTT,
but only for the case when them
are accessed at replica. And it is not included in this patch, because
everybody think that access to GTT
replica should be considered in separate patch.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Yet another version of my GTT patch addressing issues reported by
曾文旌(义从)
* Bug in TRUNCATE is fixed,
* ON COMMIT DELETE ROWS option is supported
* ALTER TABLE is correctly handled
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git
á 23. 8. 2019 v 16:32 odesílatel Konstantin Knizhnik <
> k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>>
napsal:
>
> >
> >
> > On 23.08.2019 14:42, Pavel Stehule wrote:
> >
> >
> > In
ementation?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
proposed by Pavel).
I afraid that it may break compatibility with some existed extensions
and applications.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index ae7b729
information about GTT in shared
memory. Looks like the only information we really need to share is
table's metadata.
But it is already shared though catalog. All other GTT related
information is private to backend so I do not see reasons to place it in
shared memory.
--
Konstantin Knizhn
insert into gtt values (generate_series(1,10),
generate_series(1,10));
INSERT 0 10
postgres=# create index on gtt(y);
ERROR: can not create index when have one or more backend attached this
global temp table
I wonder why do you need such restriction?
--
Konstantin Knizhnik
Postgr
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...@po
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
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
not in pg_statistic table itself.
To do it I have to add InsertSysCache/InsertCatCache functions which
insert pinned entry in the correspondent cache.
I wonder if there are some pitfalls of such approach?
New patch for GTT is attached.
--
Konstantin Knizhnik
Postgres Professional: http://
agree on this point, perhaps it isn't
necessary to argue about those things right now.
Ok.
I attached new patch for GTT with local (private) buffer and no replica
access.
It provides GTT for all built-in indexes
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The
On 28.10.2019 15:13, Robert Haas wrote:
On Fri, Oct 25, 2019 at 12:22 PM Konstantin Knizhnik
wrote:
On 25.10.2019 18:01, Robert Haas wrote:
On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
wrote:
Just to clarify.
I have now proposed several different solutions for GTT:
Shared vs
201 - 300 of 696 matches
Mail list logo
