[HACKERS] transam README small fix

also changed it to actual call nesting. transam.readme.patch Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] transam README small fix

Thanks. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company > On 04 Mar 2016, at 22:14, Robert Haas wrote: > > On Tue, Mar 1, 2016 at 4:31 AM, Stas Kelvich wrote: >> Transaction function call sequence description in transam/REA

[HACKERS] 2PC support for pglogical

. pglogical_twophase.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] Tsvector editing functions

> Seems reasonable, done. tsvector_ops-v6.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] Tsvector editing functions

> > On 11 Mar 2016, at 16:13, Stas Kelvich wrote: > > >> On 10 Mar 2016, at 20:29, Teodor Sigaev wrote: >> >> I would like to suggest rename both functions to array_to_tsvector and >> tsvector_to_array to have consistent name. Later we could add >&g

Re: [HACKERS] Speedup twophase transactions

by Alvaro and Michael down thread Done. Originally I thought about reducing number of tests (11 right now), but now, after some debugging, I’m more convinced that it is better to include them all, as they are really testing different code paths. > * Add documentation for RecoverPreparedF

Re: [HACKERS] async replication code

ic/warm-standby.html#STREAMING-REPLICATION --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] eXtensible Transaction Manager API (v2)

r thread that counts all money in system: select sum(v) from t; So in transactional system we expect that sum should be always constant (zero in our case, as we initialize user with zero balance). But we can see that without tsdtm total amount of money fluctuates around zero. https://github.com/ke

Re: [HACKERS] fd.c: flush data problems on osx

erstand why are they happening. > > Greetings, > > Andres Freund > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers --- Stas Kelvich Postgres Pro

[HACKERS] fd.c: flush data problems on osx

there any check that will guarantee that pg_flush_data will not end up with empty body on some platform? --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company # Minimal test testing streaming replication use strict; use warnings; use PostgresNode; use TestLib;

Re: [HACKERS] fd.c: flush data problems on osx

> On 18 Mar 2016, at 14:45, Stas Kelvich wrote: >> >>> One possible solution for that is just fallback to pg_fdatasync in case >>> when offset = nbytes = 0. >> >> Hm, that's a bit heavyweight. I'd rather do an lseek(SEEK_END) to get >>

Re: [HACKERS] fd.c: flush data problems on osx

e > offset = 0, nbytes = 0 case (via fseek(SEEK_END). It is already in this diff. I’ve added this few messages ago. flushdata.v4.patch Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing li

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

box > as a point in 4-dimensional space? Or just say 4-d vector instead of 4-d point. Look like it will be enough rigorous. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

imensions number is higher than 10-20, intarray performs bad on data with big sets of possible coordinates, this patch is also intended to help with specific, niche problem. While people tends to use machine learning and regressions models more and more it is interesting to have some general n-d

Re: [HACKERS] 2PC support for pglogical

> On 24 Mar 2016, at 17:03, Robert Haas wrote: > > On Wed, Mar 23, 2016 at 1:44 AM, Craig Ringer wrote: >> On 10 March 2016 at 22:50, Stas Kelvich wrote: >>> Hi. >>> >>> Here is proof-of-concept version of two phase commit support for logical >

Re: [HACKERS] Speedup twophase transactions

On Mar 29, 2016, at 6:04 PM, David Steele wrote:It looks like you should post a new patch or respond to Michael's comments.  Marked as "waiting on author".Yep, here it is.On Mar 22, 2016, at 4:20 PM, Michael Paquier wrote:Looking at this patch….Than

Re: [HACKERS] Speedup twophase transactions

My +1 for moving function to xlogutils.c too. Now call to this function goes through series of callbacks so it is hard to find it. Personally I found it only after I have implemented same function by myself (based on code in pg_xlogdump). Stas Kelvich Postgres Professional: http

Re: [HACKERS] Speedup twophase transactions

check.sh Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company > On 12 Jan 2016, at 22:57, Simon Riggs wrote: > > On 12 January 2016 at 18:14, Andres Freund wrote: > Hi, > > Thank you for the additional review. >

Re: [HACKERS] Speedup twophase transactions

Agree, I had the same idea in my mind when was writing that script. I will migrate it to TAP suite and write a review for Michael Paquier's patch. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company > On 26 Jan 2016, at 20:20, Alvaro Herrer

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

Hi. I tried that and confirm strange behaviour. It seems that problem with small cyrillic letter ‘х’. (simplest obscene language filter? =) That can be reproduced with simpler test Stas test.c Description: Binary data > On 27 Jan 2016, at 13:59, Artur Zakirov wrote: > > On 27.01.2016 13

Re: [HACKERS] Tsvector editing functions

quot;unrecognized weight: %d" > (instead of %c) in tsvector_setweight_by_filter. > Ah, I was thinking about moving it to separate diff and messed. Fixed and attaching diff with same fix for old tsvector_setweight. tsvector_ops-v2.1.diff Description: Binary data tsvector_ops-v2.2.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc.

ing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] tsearch_extras extension

so I think we can ask commiter to mention you in commit message (if it that will be commited). And how do you use ts_match_locs_array / ts_match_locs_array? To highlight search results? There is function called ts_headline that can mark matches with custom start/stop strings. --- Stas Kelvich Postgr

Re: [HACKERS] Tsvector editing functions

! Fixed and added tests. > -- > Teodor Sigaev E-mail: teo...@sigaev.ru > WWW: http://www.sigaev.ru/ > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.

Re: [HACKERS] Logical decoding restart problems

tput plugin, and current postgres master). -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical decoding restart problems

> On 31 Aug 2016, at 03:28, Craig Ringer wrote: > > On 25 Aug. 2016 20:03, "Stas Kelvich" wrote: > > > > Thanks for clarification about how restart_lsn is working. > > > > Digging slightly deeper into this topic revealed that problem was in two

Re: [HACKERS] Speedup twophase transactions

> On 06 Sep 2016, at 04:41, Michael Paquier wrote: > > On Sat, Sep 3, 2016 at 10:26 PM, Michael Paquier > wrote: >> On Fri, Sep 2, 2016 at 5:06 AM, Simon Riggs wrote: >>> On 13 April 2016 at 15:31, Stas Kelvich wrote: >>> >>>> Fixed patch at

Re: [HACKERS] Speedup twophase transactions

> On 06 Sep 2016, at 12:09, Simon Riggs wrote: > > On 6 September 2016 at 09:58, Stas Kelvich wrote: >> >> I'll check it against my failure scenario with subtransactions and post >> results or updated patch here. > > Make sure tests are added for that.

Re: [HACKERS] Speedup twophase transactions

> On 07 Sep 2016, at 03:09, Michael Paquier wrote: > >>> On 06 Sep 2016, at 12:03, Michael Paquier wrote: >>> >>> On Tue, Sep 6, 2016 at 5:58 PM, Stas Kelvich >>> wrote: >>>> Oh, I was preparing new version of patch, after fresh look

[HACKERS] Bug in two-phase transaction recovery

hile looking at StandbyRecoverPreparedTransactions() i’ve noticed that buffer for 2pc file is allocated in TopMemoryContext but never freed. That probably exists for a long time. gidlen_fixes.diff Description: Binary data standby_recover_pfree.diff Description: Binary data -- Stas K

Re: [HACKERS] Suggestions for first contribution?

https://www.postgresql.org/docs/current/static/gist-extensibility.html -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

> On 07 Sep 2016, at 11:07, Stas Kelvich wrote: > >> On 07 Sep 2016, at 03:09, Michael Paquier wrote: >> >>>> On 06 Sep 2016, at 12:03, Michael Paquier >>>> wrote: >>>> >>>> On Tue, Sep 6, 2016 at 5:58 PM, Stas Kelvich

Re: [HACKERS] Speedup twophase transactions

that is possible even without DSM, it possible to allocate static sized array storing some info about tx, whether it is in the WAL or in file, xid, gid. Some sort of PGXACT doppelganger only for replay purposes instead of using normal one. So taking into account my comments what do you think? Should we kee

Re: [HACKERS] Speedup twophase transactions

> On 21 Sep 2016, at 10:32, Michael Paquier wrote: > > On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich > wrote: >> >> Putting that before actual WAL replay is just following historical order of >> events. >> Prepared files are pieces of WAL that happened be

[HACKERS] assert violation in logical messages serialization

-- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Issues with logical replication

tLockTableWait() and it seems that it is used mostly with xids from heap so tx definetly set it lock somewhere in the past. Not sure what it the best approach to handle that. May be write running xacts only if they already set their lock? Also attaching pgbench script that ca

Re: [HACKERS] WIP: About CMake v2

. During commitfests CMake build system will > be supported by me. > I need help with buildfarm because my knowledge of Perl is very bad (thought > about rewrite buildfarm to Python). > > I hope for your support. Tried to generate Xcode project out of cmake, build fail

[HACKERS] Stats sender and 2pc minor problem

live_tup = 3 instead of 0. Fix along with test is attached. 2pc-stats.patch Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] logical decoding of two-phase transactions

be, I’m failing to understand some points. Can we maybe setup skype call to discuss this and post summary here? Craig? Peter? -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

Re: [HACKERS] logical decoding of two-phase transactions

rm prepare decoding with some kind of copied-end-edited snapshot. I’ll have a look at this. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical decoding of two-phase transactions

> On 16 Mar 2017, at 14:44, Craig Ringer wrote: > > I'm going to try to pick this patch up and amend its interface per our > discussion earlier, see if I can get it committable. I’m working right now on issue with building snapshots for decoding prepared tx. I hope I'll send updated patch later

Re: [HACKERS] logical decoding of two-phase transactions

of decoding prepare record we already know that it is aborted than such decoding doesn’t have a lot of sense. IMO intended usage of logical 2pc decoding is to decide about commit/abort based on answers from logical subscribers/replicas. So there will be barrier between prepare and commit/abort and s

Re: [HACKERS] logical decoding of two-phase transactions

shot struct to force filtering xmax > snap->xmax or xmin = snap->xmin as Petr suggested. Then this logic can reside in ReorderBufferCommit(). However this is not solving problem with catcache, so I'm looking into it right now. > On 17 Mar 2017, at 05:38, Craig Ringer wrote: >

Re: [HACKERS] logical decoding of two-phase transactions

or > something, to make it clear what we're doing. Yes, that will be less confusing. However there is no any kind of queue, so SnapBuildStartPrepare / SnapBuildFinishPrepare should work too. > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7

Re: [HACKERS] logical decoding of two-phase transactions

> On 20 Mar 2017, at 16:39, Craig Ringer wrote: > > On 20 March 2017 at 20:57, Stas Kelvich wrote: >> >>> On 20 Mar 2017, at 15:17, Craig Ringer wrote: >>> >>>> I thought about having special field (or reusing one of the existing >>>>

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

> On 23 Mar 2017, at 15:53, Craig Ringer wrote: > > On 23 March 2017 at 19:33, Alexey Kondratov > wrote: > >> (1) Add errors handling to COPY as a minimum program > > Huge +1 if you can do it in an efficient way. > > I think the main barrier to doing so is that the naïve approach > creates

Re: [HACKERS] logical decoding of two-phase transactions

lised that it is not useful for the main case when commit/abort is generated after receiver side will answer to prepares. Also that two-pass scan is a massive change in relcache.c and genam.c (FWIW there were no problems with cache, but some problems with index scan and handling one-to-m

Re: [HACKERS] logical decoding of two-phase transactions

> On 27 Mar 2017, at 16:29, Craig Ringer wrote: > > On 27 March 2017 at 17:53, Stas Kelvich wrote: > >> I’m heavily underestimated amount of changes there, but almost finished >> and will send updated patch in several hours. > > Oh, brilliant! Please post what

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:19, Stas Kelvich wrote: > > * It is actually doesn’t pass one of mine regression tests. I’ve added > expected output > as it should be. I’ll try to send follow up message with fix, but right now > sending it > as is, as you asked. > >

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:25, Andres Freund wrote: > > Hi, > > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: >> Ok, here it is. > > On a very quick skim, this doesn't seem to solve the issues around > deadlocks of prepared transactions vs. catalog tables.

Re: [HACKERS] logical decoding of two-phase transactions

us one, that implements logic i’ve just described. There is runtest.sh script that setups postgres, runs python logical consumer in background and starts regression test. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company logical_twophase_v5.diff Descriptio

Re: [HACKERS] logical decoding of two-phase transactions

such cases and it is hard to address or argue about. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company logical_twophase_v6.diff Description: Binary data logical_twophase_regresstest.diff Description: Binary data -- Sent via pgsql-hackers m

Re: [HACKERS] logical replication worker and statistics

eplication workers are collected. >> For example, this can prevent autovacuum from working on >> those tables properly. > > Yeah, that doesn't sound good. Seems that nobody is working on this, so i’m going to create the patch. Stas Kelvich Postgres Professional:

Re: [HACKERS] logical replication worker and statistics

> On 10 Apr 2017, at 05:20, Noah Misch wrote: > > On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote: >>> On 27 Mar 2017, at 18:59, Robert Haas wrote: >>> On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote: >>>> Logical replicatio

Re: [HACKERS] logical replication worker and statistics

> On 10 Apr 2017, at 19:50, Peter Eisentraut > wrote: > > On 4/10/17 05:49, Stas Kelvich wrote: >> Here is small patch to call statistics in logical worker. Originally i >> thought that stat >> collection during logical replication should manually account amounts

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

’t cancel transaction. At least when COPY called outside of transaction block. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Failed recovery with new faster 2PC code

> Stas, I thought this patch was very important to you, yet two releases > in a row we are too-late-and-buggy. I’m looking at pgstat issue in nearby thread right now and will switch to this shortly. If that’s possible, I’m asking to delay revert for several days. Stas Kelvich Postgres

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

ilure, this happens under tablesync worker and putting pgstat_report_stat() under the previous condition block should help. However for me it took about an hour of running this script to catch original assert. Can you check with that patch applied? logical_worker.patch Description: Binary data St

[HACKERS] Logical replication ApplyContext bloat

. applycontext_bloat.patch Description: Binary data Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 12:37, Petr Jelinek wrote: > > On 18/04/17 13:45, Stas Kelvich wrote: >> Hi, >> >> currently logical replication worker uses ApplyContext to decode received >> data >> and that context is never freed during transaction processi

Re: [HACKERS] Logical replication ApplyContext bloat

ll reset at the end of each function involved. > > -- > Simon Riggs http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- S

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 14:30, Petr Jelinek wrote: > > On 19/04/17 12:46, Stas Kelvich wrote: >> >> Right now ApplyContext cleaned after each transaction and by this patch I >> basically >> suggest to clean it after each command counter increment. >

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 16:07, Alvaro Herrera wrote: > > Stas Kelvich wrote: > >> With patch MemoryContextStats() shows following hierarchy during slot >> operations in >> apply worker: >> >> TopMemoryContext: 83824 total in 5 blocks; 9224 free (8

Re: [HACKERS] Dynamic instrumentation of lwlock wait times (lwlock flamegraphs)

stack, waiter > stack > - ... > > I think it might be interesting to collect a few of these somewhere > centrally once halfway mature. Maybe in src/tools or such. Wow, that’s extremely helpful, thanks a lot. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Transactions involving multiple postgres foreign servers

ther isolation nor atomicity. And if one isn’t doing cross-node analytical transactions it will be safe to live without isolation. But living without atomicity means that some parts of data can be lost without simple way to detect and fix that. Stas Kelvich Postgres Professional: http://www.p

Re: [HACKERS] Transactions involving multiple postgres foreign servers

com/en-us/research/wp-content/uploads/2016/02/samehe-clocksi.srds2013.pdf [4] https://github.com/ept/hermitage Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Logical replication ApplyContext bloat

> On 20 Apr 2017, at 17:01, Dilip Kumar wrote: > > On Thu, Apr 20, 2017 at 7:04 PM, Stas Kelvich > wrote: >> Thanks for noting. >> >> Added short description of ApplyContext and ApplyMessageContext to README. > > Typo > > /analysys/analysis >

Re: [HACKERS] Logical replication ApplyContext bloat

plies), not only some messages. > > Committed that. > >> Also, perhaps ApplyMessageContext should be a child of >> TopTransactionContext. (You have it as a child of ApplyContext, which >> is under TopMemoryContext.) > > Left that as is. Thanks! Stas Kelvich Postgre

Re: [HACKERS] snapbuild woes

not fsync file "pg_logical/mappings/map-4000-4df-0_A4EA29F8-5aa5-5ae6": Too many open files in system I’m not sure whether this is boils down to some of the previous issues mentioned here or not, so posting here as observation. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical decoding of two-phase transactions

ter to just forbid to prepare such transactions. Otherwise if some realistic examples that can block decoding are actually exist, then we probably need to reconsider the way tx being decoded. Anyway this part probably need Andres blessing. Stas Kelvich Postgres Professional: http://www.postgrespro.com

[HACKERS] Cube extension kNN support

ring suggested syntax with minus before coordinate. This request selects rows ordered descending by 4th coordinate: SELECT * FROM objects ORDER BY objects.coord->-4 LIMIT 10; Stas Kelvich. distances.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Cube extension point support // GSoC'13

system (OSX) it is second option in both situations. I've also tested it on FreeBSD 9.0 and Ubuntu 12.04 with the same results. So is there some ideas how can I reproduce such results? Stas. points.diff Description: Binary data On Sep 16, 2013, at 10:48 AM, Heikki Linnakangas wrote

[HACKERS] Cube extension types support

Hello, hackers. In this patch I've implemented support for different storage types for cubes. Now it supports float8, float4, int4, int2, int1. Type stored in the header of each cube, one for all coordinates. So for cubes with int1 coordinates it can save up to 8x disk space. Typed cubes can be

[HACKERS] Cube extension split algorithm fix

Hello, hackers. I've fixed split algorithm that was implemented in cube extension. I've changed it according to the original Guttman paper (old version was more simple algorithm) and also ported Alexander Korotkov's algorithm from box datatype indexing that work faster and better on low dimensi

[HACKERS] Tsvector editing functions

[] to_array(tsvector) converts tsvector to array of lexemes tsvector to_tsvector(text[]) converts array of lexemes to tsvector tsvector_funcs.diff Description: Binary data Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql

Re: [HACKERS] Cube extension kNN support

2015, at 16:40, Alexander Korotkov wrote: > > Hi! > > On Sat, May 9, 2015 at 6:53 AM, Stas Kelvich wrote: > Patch is pretty ready, last issue was about changed extension interface, so > there should be migration script and version bump. > Attaching a version with all migration

Re: [HACKERS] Cube extension kNN support

Documentation along with style fix. distances2r3.patch Description: Binary data > On 08 Feb 2015, at 00:32, Alexander Korotkov wrote: > > Hi! > > On Sat, Feb 7, 2015 at 12:45 PM, Stas Kelvich wrote: > I had updated old patch with kNN operators for cube data s

Re: [HACKERS] Cube extension kNN support

t; Sergey Konoplev wrote: >> On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev wrote: >>> On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich >>> wrote: >>>> Here is the patch that introduces kNN search for cubes with euclidean, >>>> taxicab and cheby

Re: [HACKERS] Tsvector editing functions

Hello. Done with the list of suggestions. Also heavily edit delete function. tsvector_ops.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company > On 27 Nov 2015, at 15:13, Teodor Sigaev wrote: > > Hmm, seems, i

Re: [HACKERS] Cube extension kNN support

Hello, fixed. cube_distances.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company > On 01 Dec 2015, at 17:52, Teodor Sigaev wrote: > > Patch looks good, but there ara some review notices: > 1 gmake instal

[HACKERS] Speedup twophase transactions

abalance = abalance + :delta WHERE aid = :to_aid; PREPARE TRANSACTION ':client_id.:scale'; COMMIT PREPARED ':client_id.:scale'; 2pc_xlog.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Se

Re: [HACKERS] Speedup twophase transactions

Thanks, Kevin. > I assume that last one should have been *Patched master with 2PC”? Yes, this list should look like this: Current master without 2PC: ~42 ktps Current master with 2PC: ~22 ktps Patched master with 2PC: ~36 ktps And created CommitFest entry for this patch. -- Stas Kelv

Re: [HACKERS] Speedup twophase transactions

i thought that pgbench will change aid columns to bigint if scale is more than 2. 2pc_xlog.v2.diff Description: Binary data --- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Cube extension kNN support

hould be (1,1),(3,3) Updated patch attached. cube_distances.patch Description: Binary data > On 15 Dec 2015, at 21:46, Tomas Vondra wrote: > > Hi, > > On 12/07/2015 03:47 PM, Stas Kelvich wrote: >> Hello, fixed. > > I've looked at the patch tod

Re: [HACKERS] Cube extension kNN support

Dec 2015, at 16:46, Tomas Vondra wrote: > > Hi, > > On 12/16/2015 01:26 PM, Stas Kelvich wrote: >> Hi, thanks for the review. >> >>> 1) (nitpicking) There seem to be some minor whitespace issues, i.e. >>> trailing spaces, empty lines being added/removed, etc.

Re: [HACKERS] Tsvector editing functions

arameter ones should. > Fixed. > 7) Some of the functions use intexterm that does not match the function > name. I see two such cases - to_tsvector and setweight. Is there a > reason for that? > Because sgml compiler wants unique indexterm. Both functions that you mentioned

Re: [HACKERS] Speedup twophase transactions

Description: Binary data Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company > On 08 Jan 2016, at 19:29, Alvaro Herrera wrote: > > Simon Riggs wrote: > >> I think we could do better still, but this looks like the easiest 80% and >&g

Re: [HACKERS] Speedup twophase transactions

erence, but I think it is good idea to keep GXact as small as possible. As far as I understand the same logic was behind split of PGPROC to PGPROC+PGXACT in 9.2 (comment in proc.h:166) Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-h

Re: [HACKERS] Speedup twophase transactions

e transaction context and release it only if next command isn’t our designated COMMIT/ROLLBACK. But that is a big amount of work and requires changes to whole transaction pipeline in postgres. Anyway I suggest that we should consider that as a separate task. --- Stas Kelvich Postgres Professional

Re: [HACKERS] Speedup twophase transactions

be > executed in parallel. That’s interesting observation. Simon already pointed me to this problem in 2pc replay, but I didn’t thought that it is so slow. I’m now working on that. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hacke

[HACKERS] Cube extension improvement, GSoC

Hello, some time ago I started working on the data search system (about 100-200M of records) with queries consisted of several diapason and equality conditions, e.g.: WHERE dim1 BETWEEN 128 AND 137 AND WHERE dim2 BETWEEN 4815 AND 162342 AND WHERE dim3 = 42 ORDER BY dim1 ASC There are 6

Re: [HACKERS] Cube extension improvement, GSoC

rrays and declare operations of > that domain. But what we should do when arrays in different records have different numbers of element? Stas Kelvich. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Cube extension improvement, GSoC

ay 4, 2013 at 11:19 PM, Stas Kelvich wrote: > > I think we have at least 3 data types more or less similar to cube. > > 1) array of ranges > > 2) range of arrays > > 3) 2d arrays > > Semantically cube is most close to array or ranges. However array of ranges > >

Re: [HACKERS] Cube extension improvement, GSoC

On May 14, 2013, at 4:53 PM, Alexander Korotkov wrote: > Sounds promising. Did you examine how this technique can fit into GiST? In > current GiST interface methods don't have access to parent entries. No, i didn't examine it yet. Anyway in this technique lots of changes should be performed to

Re: [HACKERS] Cube extension kNN support

3 ms As we can see, kNN ordering 10 times slower than B-tree (on silly request for R-Tree, just as example), but still 100+ times faster than full scan on this table. Stas. On Sep 25, 2013, at 5:25 PM, Peter Eisentraut wrote: > On 9/22/13 7:38 PM, Stas Kelvich wrote: >> Here is t

Re: [HACKERS] Speedup twophase transactions

last segment: 0x47 patched, with constant cache_drop: total recovery time: 86s patched, without constant cache_drop: total recovery time: 68s (while difference is significant, i bet that happens mostly because of database file segments should be re-read after cache drop) master, without

Re: [HACKERS] logical decoding of two-phase transactions

we should invent something more nasty like writing them into a table. > That should eliminate Simon's > objection re the cost of tracking GIDs and still let us have access to > them when we want them, which is the best of both worlds really. Having 2PC decoding in core is a good thi

Re: [HACKERS] Speedup twophase transactions

sewhere. Thanks Nikhil, now I got that. Since we are talking about promotion we are on different timescale and 1-10 second lag matters a lot. I think I have in my mind realistic scenario when proposed recovery code path will hit the worst case: Google cloud. They have quite fast storage, but fs

Re: [HACKERS] logical decoding of two-phase transactions

/ABORT decoded and sent After step 3 there is no more memory state associated with that prepared tx, so if will fail between 3 and 4 then we can’t know GID unless we wrote it commit record (or table). -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] logical decoding of two-phase transactions

194-byte GID’s difference in WAL size is about 18% So using big GID’s (as J2EE does) can cause notable WAL bloat, while small GID’s are almost unnoticeable. May be we can introduce configuration option track_commit_gid by analogy with track_commit_timestamp and make that beh

  1   2   >