d patch with these suggested minor
improvements, please take a look and see what you think (please
compare with the original patch).
Thank you very much for detecting the problems and much more thanks for
fixing them and providing your version of the patch.
I have nothing against renaming &q
Hi hackers!
Due to the error in PG-ProEE we have added the following test to
pg_visibility:
create table vacuum_test as select 42 i;
vacuum vacuum_test;
select count(*) > 0 from pg_check_visible('vacuum_test');
drop table vacuum_test;
Sometime (very rarely) this test failed: pg_visibility rep
On 06.12.2020 23:50, Konstantin Knizhnik wrote:
Hi hackers!
Due to the error in PG-ProEE we have added the following test to
pg_visibility:
create table vacuum_test as select 42 i;
vacuum vacuum_test;
select count(*) > 0 from pg_check_visible('vacuum_test');
drop tabl
ishing)
tps = 995.525383 (excluding connections establishing)
As you can see - there is almost now different (patched version is even
faster, but it seems to be just "white noise".
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 10.12.2020 10:45, Pavel Stehule wrote:
st 9. 12. 2020 v 14:28 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 09.12.2020 15:34, Pavel Stehule wrote:
Hi
st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow
mailto:gregn4...@gmail.com>
On 10.12.2020 18:12, Pavel Stehule wrote:
My idea was a little bit different. Inside postinit initialize some
global variables with info if there are event triggers or not. And
later you can use this variable to start transactions and other things.
There will be two access to pg_event_tri
On 10.12.2020 21:09, Pavel Stehule wrote:
čt 10. 12. 2020 v 16:48 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 10.12.2020 18:12, Pavel Stehule wrote:
My idea was a little bit different. Inside postinit initialize
some global variable
isable_event_triggers GUC check.
And this option should be defined with PGC_SU_BACKEND
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
le to define on
connection triggers and
should not have rights to disable them.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 11.12.2020 19:27, Pavel Stehule wrote:
pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 11.12.2020 18:40, Pavel Stehule wrote:
is not correct. It makes it not possible to superuser to
disable triggers f
On 15.12.2020 16:18, Pavel Stehule wrote:
út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 11.12.2020 19:27, Pavel Stehule wrote:
pá 11. 12. 2020 v 17:05 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgres
On 15.12.2020 18:25, Pavel Stehule wrote:
út 15. 12. 2020 v 15:06 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 15.12.2020 16:18, Pavel Stehule wrote:
út 15. 12. 2020 v 14:12 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgres
trigger is created.
This flag is never cleaned (to avoid visibility issues mentioned in my
previous mail).
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/event-trigger.sgml b/doc/src/sgml/event-trigger.sgml
index
o
enable_connection_trigger.
New version of the patch is attached.
--
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 f810789..45d30b3 100644
--- a/doc/src/sgml/config
e too long).
Thank you, fixed.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
).
I am maintaining this code in
g...@github.com:postgrespro/libpq_compression.git repository.
I will be pleased if anybody, who wants to suggest any bug
fixes/improvements of libpq compression, create pull requests: it will
be much easier for me to merge them.
--
Konstantin Knizhnik
Postgres
if somebody in the past faced with the similar symptoms and
was this problem with holding locks of two partitions in bufmgr already
discussed?
P.S.
The customer is using 9.6 version of Postgres, but I have checked that
the same code fragment is present in the master.
--
Konstantin Knizhnik
P
On 19.12.2020 10:53, Zhihong Yu wrote:
Hi,
w.r.t. the code in BufferAlloc(), the pointers are compared.
Should we instead compare the tranche Id of the two LWLock ?
Cheers
As far as LWlocks are stored in the array, comparing indexes in this
array (tranche Id) is equivalent to comparing ele
On 20.12.2020 10:04, Pavel Stehule wrote:
čt 17. 12. 2020 v 19:30 odesílatel Pavel Stehule
mailto:pavel.steh...@gmail.com>> napsal:
čt 17. 12. 2020 v 14:04 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 17.12.2020 9:31, P
paring with any other tablepsace.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
... FAILED 626 ms
== shutting down postmaster ==
Sorry, fixed.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml
index 036a72c..bb62f25
On 22.12.2020 22:03, Tom Lane wrote:
Tomas Vondra writes:
I don't see aby benchmark results in this thread, allowing me to make
that conclusion, and I find it hard to believe that 200MB/client is a
sensible trade-off.
It assumes you have that much memory, and it may allow easy DoS attack
(al
On 22.12.2020 21:19, Pavel Stehule wrote:
út 22. 12. 2020 v 12:42 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 22.12.2020 12:25, Pavel Stehule wrote:
regress tests fails
sysviews ... FAILED 112 ms
On 19.08.2020 22:20, Pavel Stehule wrote:
st 19. 8. 2020 v 20:59 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 19.08.2020 21:50, Pavel Stehule wrote:
Hi
st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik
mailto:k
1000)));
INSERT INTO toasted(data) VALUES((SELECT string_agg(random()::text,':')
FROM generate_series(1, 1000)));
DO $$ DECLARE v_r record; BEGIN FOR v_r in SELECT data FROM toasted LOOP
INSERT INTO toasted(data) VALUES(v_r.data);COMMIT;END LOOP;END;$$;
--
Konstantin Knizhn
on-trivial)
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 19.02.2021 10:14, Pavel Stehule wrote:
pá 19. 2. 2021 v 7:51 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 18.02.2021 20:10, Pavel Stehule wrote:
This has a negative impact on performance - and a lot of users
use procedures w
On 19.02.2021 10:47, Pavel Stehule wrote:
pá 19. 2. 2021 v 8:39 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 19.02.2021 10:14, Pavel Stehule wrote:
pá 19. 2. 2021 v 7:51 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgres
Thank you for your feedback.
On 19.02.2021 6:25, Tomas Vondra wrote:
On 1/22/21 5:04 PM, Konstantin Knizhnik wrote:
...
I have heard from several DBMS experts that appearance of huge and
cheap non-volatile memory can make a revolution in database system
architecture. If all database can fit
On 19.02.2021 11:12, Pavel Stehule wrote:
pá 19. 2. 2021 v 9:08 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> napsal:
On 19.02.2021 10:47, Pavel Stehule wrote:
pá 19. 2. 2021 v 8:39 odesílatel Konstantin Knizhnik
mailto:k.knizh...@postgres
On 22.02.2021 23:44, Tom Lane wrote:
Robert Haas writes:
So at the end of the day I'm not really quite sure what is best here.
I agree with all of Craig's points about the advantages of
packet-level compression, so I'd really prefer to make that approach
work if we can. However, it also seem
On 22.02.2021 08:38, Craig Ringer wrote:
On Thu, 11 Feb 2021, 21:09 Daniil Zakhlystov,
mailto:usernam...@yandex-team.ru>> wrote::
3. Chunked compression allows to compress only well compressible
messages and save the CPU cycles by not compressing the others
4. Chunked compress
On 27.02.2021 20:40, AJG wrote:
Hi,
Greatly appreciate if you could please reply to the following questions as
time allows.
I have seen previous discussion/patches on a built-in connection pooler. How
does this scalability improvement, particularly idle connection improvements
etc, affect th
On 11.03.2021 03:47, Tomas Vondra wrote:
Hi Konstantin,
Thanks for working on this! Using extended statistics to improve join
cardinality estimates was definitely on my radar, and this patch seems
like a good start.
I had two basic ideas about how we might improve join estimates:
(a) use pe
ny check preventing cutoff_xid to be greater than
XID of some transaction which was aborted long time ago.
So is there some logical error that xmax is compared with cutoff_xid
before HEAP_XMAX_INVALID bit is checked?
Otherwise, where this constraint most likely be violated?
It is PG 11.7 vers
On 28.10.2020 18:25, Mark Dilger wrote:
On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik
wrote:
Looks like there is no assumption that xmax should be set to
InvalidTransactionId when HEAP_XMAX_INVALID bit is set.
And I didn't find any check preventing cutoff_xid to be greater tha
4 (pqReadData read CompressionAck (6 bytes) and compressed
AuthenticationOk (18 bytes) came after it)
pqReadData RC: 1
psql: error: could not connect to server: expected authentication
request from server, but received x // FAIL
Thank you for reporting the problem.
Fix is attached.
--
Konstant
x27;s a mistake to deal
with this in the startup packet anyway.
Sorry, I think that it should be quite easy for user to toggle compression.
Originally I suggest to add -z option to psql and other Postgres
utilities working with libpq protocol.
Adding new options was considered by reviewer
New version of the patch with fixed is attached.
On 28.10.2020 22:27, Andres Freund wrote:
Hi,
On 2020-10-26 19:20:46 +0300, Konstantin Knizhnik wrote:
diff --git a/configure b/configure
index ace4ed5..deba608 100755
--- a/configure
+++ b/configure
@@ -700,6 +700,7 @@ LD
LDFLAGS_SL
On 28.10.2020 22:58, Alvaro Herrera wrote:
On 2020-Oct-26, Konstantin Knizhnik wrote:
+ while (bufptr < bufend || zpq_buffered(PqStream) != 0) /* has more data
to flush or unsent data in internal compression buffer */
{
- int
Hi
On 31.10.2020 00:03, Andres Freund wrote:
Hi,
On 2020-10-29 16:45:58 +0300, Konstantin Knizhnik wrote:
- What does " and it is up to the client whether to continue work
without compression or report error" actually mean for a libpq parameter?
It can not happen.
The client re
Hi
On 01.11.2020 12:37, Daniil Zakhlystov wrote:
Hi,
I have a couple of comments regarding the last patch, mostly these are
minor issues.
In src/backend/libpq/pqcomm.c, starting from the line 1114:
int
pq_getbyte_if_available(unsigned char *c)
{
intr;
Assert(PqCommReadingMsg);
if (PqRecvP
0
22270 | 0 | 0 | 0
| 0
22269 | 0 | 0 | 0
| 0
22271 | 0 | 0 | 0
| 0
(7 rows)
--
Konstantin Knizhnik
Postgres Pro
y the attached patch v24 which adds zpq_buffered_rx and
zpq_buffered_tx functions.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/configure b/configure
index ace4ed5..deba608 100755
--- a/configure
+++ b/configure
@@ -700,6 +700,7
On 02.11.2020 19:53, Matthias van de Meent wrote:
This is the result of network traffic of two backends one with enabled
compression and another with disable compression
after execution of "select * from pg_class" command:
select * from pg_stat_network_traffic;
pid | rx_raw_bytes | tx_r
PR is attached to this mail .
The latest version of libpq sources can be also found in git repository:
g...@github.com:postgrespro/libpq_compression.git
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/configure b/configure
index ac
a.
Yes, first few bytes exchanged by client and server during handshake are
not compressed.
But them are correctly calculated as "raw bytes". And certainly this few
bytes can not have any influence on
measured average compression ratio (the main goal of using this network
traffic stat
On 05.11.2020 21:07, Matthias van de Meent wrote:
On Thu, 5 Nov 2020 at 17:01, Konstantin Knizhnik
wrote:
Sorry, I do not understand your point.
This view reports network traffic from server's side.
But client's traffic information is "mirror" of this statistic:
ser
On 05.11.2020 22:22, Peter Eisentraut wrote:
On 2020-11-02 20:50, Andres Freund wrote:
On 2020-10-31 22:25:36 +0500, Andrey Borodin wrote:
But the price of compression is 1 cpu for 500MB/s (zstd). With a
20Gbps network adapters cost of recompressing all traffic is at most
~4 cores.
It's no
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I think that work on improving operator_predicate_proof should re
ict applicability of this approach.
Certainly in case of dominated read-only workload such materialized
views can significantly improve performance.
But unfortunately my dream that them allow to combine OLAP+OLPT is not
currently realized.
--
Konstantin Knizhnik
Postgres Professional: http://www
On 16.11.2020 10:11, Thomas Munro wrote:
On Tue, Aug 4, 2020 at 2:21 PM Thomas Munro wrote:
On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik
wrote:
This shared relation cache can easily store relation size as well.
In addition it will solve a lot of other problems:
- noticeable overhead
On 16.11.2020 10:11, Thomas Munro wrote:
On Tue, Aug 4, 2020 at 2:21 PM Thomas Munro wrote:
On Tue, Aug 4, 2020 at 3:54 AM Konstantin Knizhnik
wrote:
This shared relation cache can easily store relation size as well.
In addition it will solve a lot of other problems:
- noticeable overhead
two queries among 22
TPC-H have no joins).
So may be this optimization will not help much.
I wonder if it is possible to somehow use predicate locking mechanism of
Postgres to avoid this anomalies without global lock?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro
n startup package.
4. Use full names instead of one-character encoding for compression
algorithm names.
So now it is possible to open connection in this way:
psql "dbname=postgres compression=zstd:5,zlib"
New version of the patch is attached.
--
Konstantin Knizhn
On 24.11.2020 21:35, Robert Haas wrote:
On Tue, Nov 24, 2020 at 12:35 PM Daniil Zakhlystov
wrote:
To sum up, I think that the current implementation already introduces good
benefits. As I proposed in the Usability review, we may introduce the new
approaches later as separate compression 'al
On 24.11.2020 20:34, Daniil Zakhlystov wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, failed
Documentation:tested, failed
Submission
chronization between main table and
materialized view (last one may contain slightly deteriorated data).
But in this case no exclusive lock is needed, isn't it?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 25.11.2020 16:06, Yugo NAGATA wrote:
On Wed, 25 Nov 2020 15:16:05 +0300
Konstantin Knizhnik wrote:
On 24.11.2020 13:11, Yugo NAGATA wrote:
I wonder if it is possible to somehow use predicate locking mechanism of
Postgres to avoid this anomalies without global lock?
You mean that
transaction is actually aborted and
there is no chance to retry it.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 24.11.2020 22:47, Daniil Zakhlystov wrote:
I completely agree that backward-compatibility is important here.
I think that it is a good idea to clarify how the compression establishment
works in the current version of the patch:
1. Frontend send the startup packet which may look like this:
On 09.01.2021 23:31, Justin Pryzby wrote:
On Thu, Dec 17, 2020 at 05:54:28PM +0300, Konstantin Knizhnik wrote:
I am maintaining this code in
g...@github.com:postgrespro/libpq_compression.git repository.
I will be pleased if anybody, who wants to suggest any bug
fixes/improvements of libpq
On 11.01.2021 20:38, Tomas Vondra wrote:
On 1/11/21 2:53 PM, Konstantin Knizhnik wrote:
...
New version of libpq compression patch is attached.
It can be also be found at g...@github.com:postgrespro/libpq_compression.git
Seems it bit-rotted already, so here's a slightly fixed versio
On 12.01.2021 4:20, Justin Pryzby wrote:
On Mon, Jan 11, 2021 at 04:53:51PM +0300, Konstantin Knizhnik wrote:
On 09.01.2021 23:31, Justin Pryzby wrote:
I suggest that there should be an enum of algorithms, which is constant across
all servers. They would be unconditionally included and not
On 12.01.2021 18:38, Justin Pryzby wrote:
On Tue, Jan 12, 2021 at 08:44:43AM +0300, Konstantin Knizhnik wrote:
On 11.01.2021 20:38, Tomas Vondra wrote:
1) Fixes the MSVC makefile. The list of files is sorted alphabetically,
so I've added the file at the end.
Thank you
This is
if we can live
without WAL, it is still not clear whether we really want to live
without it.
One more idea: using multiword CAS approach requires us to make changes
as editing sequences.
Such editing sequence is actually ready WAL records. So implementors of
access methods do not have to do
double
Hello,
Thank you for review.
My answers are inside.
On 21.01.2021 15:30, Yugo NAGATA wrote:
Hello,
On Thu, 26 Mar 2020 18:49:51 +0300
Konstantin Knizhnik wrote:
Attached please find new version of the patch with more comments and
descriptions added.
Adaptive query optimization is very
On 27.01.2021 8:45, Yugo NAGATA wrote:
On Mon, 25 Jan 2021 16:27:25 +0300
Konstantin Knizhnik wrote:
Hello,
Thank you for review.
My answers are inside.
Thank you for updating the patch and answering my questions.
(2)
If I understand correctly, your proposal consists of the following
CV in the
clausesel patch.
Sorry, do not have idea right now how to use MCV for better estimation
of join selectivity.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/optimizer/path/clausesel.c b/src/backend/optimizer
the patch, I am afraid that we might
lose track of this unless we register it.
Yes, certainly:
https://commitfest.postgresql.org/31/2900/
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
control compression on the fly and use different
compression algorithm for TX/RX data
just complicates implementation and given no significant advantages.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 11.02.2021 16:09, Daniil Zakhlystov wrote:
Hi!
On 09.02.2021 09:06, Konstantin Knizhnik wrote:
Sorry, but my interpretation of your results is completely different:
permanent compression is faster than chunked compression (2m15 vs. 2m27)
and consumes less CPU (44 vs 48 sec).
Size of RX
On 11.01.2022 03:06, Bossart, Nathan wrote:
I noticed this thread and thought I'd share my experiences building
something similar for Multi-AZ DB clusters [0]. It's not a strict RPO
mechanism, but it does throttle backends in an effort to keep the
replay lag below a configured maximum. I can
On 19.03.2021 12:17, Yugo NAGATA wrote:
On Wed, 10 Mar 2021 03:00:25 +0100
Tomas Vondra wrote:
What is being proposed here - an extension suggesting which statistics
to create (and possibly creating them automatically) is certainly
useful, but I'm not sure I'd call it "adaptive query optimiz
"cols" is NULL and we always take first branch of the if.
In other words, at each iteration of outer loop we always make some
progress in processing "vars" list and remove some elements
from this list. So infinite loop can never happen.
Cheers
On Fri, Mar 19, 2021
People asked me to resubmit built-in connection pooler patch to commitfest.
Rebased version of connection pooler is attached.
diff --git a/contrib/spi/refint.c b/contrib/spi/refint.c
index 6fbfef2b12..27aa6cba8e 100644
--- a/contrib/spi/refint.c
+++ b/contrib/spi/refint.c
@@ -11,6 +11,7 @@
#in
Hi,
Thank you for review!
On 21.03.2021 23:59, Zhihong Yu wrote:
Hi,
+ With load-balancing policy postmaster
choose proxy with lowest load average.
+ Load average of proxy is estimated by number of clients
connection assigned to this proxy with extra weight for SSL connectio
Hi hackers.
I tried to create LSM AM which can be used instead of nbtree.
I looked at contrib/btree/gin, contrib/isn and try to do the following:
CREATE OPERATOR FAMILY lsm3_float_ops USING lsm3;
CREATE OPERATOR CLASS float4_ops DEFAULT
FOR TYPE float4 USING lsm3 FAMILY lsm3_float_ops AS
On 23.07.2020 03:11, Tom Lane wrote:
Konstantin Knizhnik writes:
But then I get error for btfloat48cmp and btfloat84cmp functions:
ERROR: associated data types must be specified for index support function
You need to specify the amproclefttype and amprocrighttype types you
want the
On 17.06.2020 09:14, k.jami...@fujitsu.com wrote:
Hi,
Since the last posted version of the patch fails, attached is a rebased version.
Written upthread were performance results and some benefits and challenges.
I'd appreciate your feedback/comments.
Regards,
Kirk Jamison
As far as i understa
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I have tested this patch at various workloads and hardware (including
Postgres provides serial and bigserial column types for which it
implicitly creates sequence.
As far as this mechanism is somehow hidden from user, it may be
confusing that table
created with CREATE TABLE LIKE has no associated sequence.
But what is worse, even if experienced user knows that se
On 03.08.2020 11:00, Peter Eisentraut wrote:
On 2020-08-01 00:06, Konstantin Knizhnik wrote:
Postgres provides serial and bigserial column types for which it
implicitly creates sequence.
As far as this mechanism is somehow hidden from user, it may be
confusing that table
created with CREATE
On 01.08.2020 00:56, Thomas Munro wrote:
On Fri, Jul 31, 2020 at 2:36 PM Thomas Munro wrote:
There's still the matter of crazy numbers of lseeks in regular
backends; looking at all processes while running the above test, I get
1,469,060 (9.18 per pgbench transaction) without -M prepared, and
Hi hackers,
I want to share results of my last research of implementing LSM index in
Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using LSM
tree instead of classical B-Tree.
From one side, capacity of RAM at modern servers allows to keep the
whole database in memo
On 04.08.2020 18:04, Alexander Korotkov wrote:
Hi!
On Tue, Aug 4, 2020 at 11:22 AM Konstantin Knizhnik
wrote:
I want to share results of my last research of implementing LSM index in
Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using LSM tree
instead of
On 04.08.2020 18:11, Tomas Vondra wrote:
On Tue, Aug 04, 2020 at 11:22:13AM +0300, Konstantin Knizhnik wrote:
Hi hackers,
I want to share results of my last research of implementing LSM index
in Postgres.
Most of modern databases (RocksDB, MongoDB, Tarantool,...) are using
LSM tree
On 04.08.2020 18:18, Stephen Frost wrote:
Independently while considering this, I don't think the issues around
how to deal with unique btrees properly has really been considered- you
certainly can't stop your search on the first tuple you find even if the
index is unique, since the "unique"
On 04.08.2020 19:53, Robert Haas wrote:
On Mon, Aug 3, 2020 at 12:35 PM Peter Eisentraut
wrote:
On 2020-08-03 14:58, Konstantin Knizhnik wrote:
May be generated and identity columns are good things. I have nothing
against them.
But what preventing us from providing the similar behavior for
On 04.08.2020 20:44, Tomas Vondra wrote:
Unique indexes are not supported now.
And I do not see some acceptable solution here.
If we will have to check presence of duplicate at the time of insert
then it will eliminate all advantages of LSM approach.
And if we postpone to the moment of merge
On 05.08.2020 02:59, Alexander Korotkov wrote:
The things you're writing makes me uneasy. I initially understood
lsm3 as a quick and dirty prototype, while you're probably keeping
some design in your mind (for instance, original design of LSM).
However, your message makes me think you're try
On 04.08.2020 20:44, Tomas Vondra wrote:
IMO the 6x difference is rather misleading, as it very much depends on
the duration of the benchmark and how much data it ends up with. I think
it's better to test 'stable states' i.e. with small data set that does
not exceed RAM during the whole test,
On 07.08.2020 00:33, Tomas Vondra wrote:
Unfortunately Konstantin did not share any details about what workloads
he tested, what config etc. But I find the "no regression" hypothesis
rather hard to believe, because we're adding non-trivial amount of code
to a place that can be quite hot.
So
On 07.08.2020 15:31, Alexander Korotkov wrote:
ср, 5 авг. 2020 г., 09:13 Konstantin Knizhnik :
Concerning degrade of basic index - B-Tree itself is balanced tree. Yes,
insertion of random keys can cause split of B-Tree page.
In the worst case half of B-Tree page will be empty. So B-Tree size
On 08.08.2020 21:18, Alexander Korotkov wrote:
On Sat, Aug 8, 2020 at 5:07 PM Konstantin Knizhnik
wrote:
I agree with your that loosing sequential order of B-Tree pages may have
negative impact on performance.
But it first of all critical for order-by and range queries, when we
should
On 09.08.2020 04:53, Alexander Korotkov wrote:
I realize that it is not true LSM.
But still I wan to notice that it is able to provide ~10 times increase
of insert speed when size of index is comparable with RAM size.
And "true LSM" from RocksDB shows similar results.
It's very far from bein
Hi hackers,
Right now jsonb functions are treated as non-shippable by postgres_fdw
and so predicates with them are not pushed down to foreign server:
create table jt(content jsonb);
create extension postgres_fdw;
create server pg_fdw FOREIGN DATA WRAPPER postgres_fdw options(host
'127.0.0.1'
On 13.08.2020 20:00, Tom Lane wrote:
Konstantin Knizhnik writes:
Right now jsonb functions are treated as non-shippable by postgres_fdw
and so predicates with them are not pushed down to foreign server:
Yeah, that's kind of annoying, but breaking the collation check
is not an accep
On 14.08.2020 09:40, Bharath Rupireddy wrote:
On Thu, Aug 13, 2020 at 8:54 PM Konstantin Knizhnik
wrote:
Right now jsonb functions are treated as non-shippable by postgres_fdw
and so predicates with them are not pushed down to foreign server:
I wonder if there is some way of making
Hi hackers,
More than month ago I have sent bug report to pgsql-bugs:
https://www.postgresql.org/message-id/flat/5d335911-fb25-60cd-4aa7-a5bd0954aea0%40postgrespro.ru
with the proposed patch but have not received any response.
I wonder if there is some other way to fix this issue and does some
1 - 100 of 699 matches
Mail list logo
