Re: [HACKERS] Partition-wise aggregation/grouping

On 11.11.2017 23:29, Konstantin Knizhnik wrote: On 10/27/2017 02:01 PM, Jeevan Chalke wrote: Hi, Attached new patch-set here. Changes include: 1. Added separate patch for costing Append node as discussed up-front in the patch-set. 2. Since we now cost Append node, we don't need

Re: [HACKERS] Partition-wise aggregation/grouping

s easier for implementation. But in case of sharded table, distributed query may need to traverse both remote and local shards and this approach doesn't allow to processed several local shards in parallel. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Comp

Re: [HACKERS] Aggregates push-down to partitions

->  Seq Scan on derived2  (cost=0.00..14425.00 rows=100 width=0) ->  Foreign Scan on derived_fdw  (cost=100.00..212.39 rows=3413 width=0) (6 rows) Are there some principle problems? -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgre

[HACKERS] Aggregates push-down to partitions

he best approach to implement this feature? -- Konstantin Knizhnik 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] SQL procedures

sh our ATX patch for Postgres 10. We have not done it yet, because there seems to be no chances to push this patch to community. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Secondary index access optimizations

On 11/06/2017 04:27 AM, Thomas Munro wrote: On Fri, Sep 8, 2017 at 3:58 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Updated version of the patch is attached to this mail. Also I added support of date type to operator_predicate_proof to be able to imply (logdate <= '2

[HACKERS] Deadlock in ALTER SUBSCRIPTION REFRESH PUBLICATION

Parallel execution of ALTER SUBSCRIPTION REFRESH PUBLICATION at several nodes may cause deadlock: knizhnik  1480  0.0  0.1 1417532 16496 ?   Ss   20:01   0:00 postgres: bgworker: logical replication worker for subscription 16589 sync 16720    waiting knizhnik  1481  0.0  0.1 1417668 17668

Re: [HACKERS] Slow synchronous logical replication

On 12.10.2017 04:23, Craig Ringer wrote: On 12 October 2017 at 00:57, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: The reason of such behavior is obvious: wal sender has to decode huge transaction generate by insert although it has no relation to this publication. It does.

Re: [HACKERS] Slow synchronous logical replication

On 11.10.2017 10:07, Craig Ringer wrote: On 9 October 2017 at 15:37, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Thank you for explanations. On 08.10.2017 16:00, Craig Ringer wrote: I think it'd be helpful if you provided reproduction instructions, test programs, etc,

Re: [HACKERS] Columnar storage support

: IMCS (In-Memory-Columnar-Store): https://github.com/knizhnik/imcs.git VOPS (Vectorized Operations): https://github.com/postgrespro/vops.git First one is more oriented on in-memory databases (although support spilling data to the disk) and requires to use special functions to manipulate

Re: [HACKERS] Slow synchronous logical replication

than other or is not updated at all (for example because communication channels between this node is broken), then all backens will stuck. Also all backends are competing for the single SyncRepLock, which also can be a contention point. -- Konstantin Knizhnik Postgres Professional: http://www.postg

Re: [HACKERS] Slow synchronous logical replication

On 10/07/2017 10:42 PM, Andres Freund wrote: Hi, On 2017-10-07 22:39:09 +0300, konstantin knizhnik wrote: In our sharded cluster project we are trying to use logical relication for providing HA (maintaining redundant shard copies). Using asynchronous logical replication has not so much sense

[HACKERS] Slow synchronous logical replication

In our sharded cluster project we are trying to use logical relication for providing HA (maintaining redundant shard copies). Using asynchronous logical replication has not so much sense in context of HA. This is why we try to use synchronous logical replication. Unfortunately it shows very bad

Re: [HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

decoding snapshot is being built and using that to skip catalog access which does not seem very pretty. It is not quite clear from the comment why it is not possible to overwrite MyPgXact->xmin or just use existed value. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.

Re: [HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

On 06.10.2017 15:29, Petr Jelinek wrote: On 06/10/17 12:16, Konstantin Knizhnik wrote: When creating logical replication slots we quite often get the following error: ERROR: cannot build an initial slot snapshot when MyPgXact->xmin already is valid which cause restart of WAL sen

[HACKERS] Issue with logical replication: MyPgXact->xmin already is valid

_t_10_3_4_17307_sync_17302\" TEMPORARY LOGICAL pgoutput USE_SNAPSHOT") at walsender.c:1515 #26 0x0088eccc in PostgresMain (argc=1, argv=0x24f0b28, dbname=0x24f0948 "postgres", username=0x24bf7f0 "knizhnik") at postgres.c:4086 #27 0x007ef9e2 in BackendR

[HACKERS] Issues with logical replication

eplication_command ( cmd_string=0x27b9520 "CREATE_REPLICATION_SLOT \"sub_17264_sync_17251\" TEMPORARY LOGICAL pgoutput USE_SNAPSHOT") at walsender.c:1511 #12 0x0088eb44 in PostgresMain (argc=1, argv=0x275b738, dbname=0x275b578 "postgres", usernam

[HACKERS] Issues with logical replication

08246ee in exec_replication_command ( cmd_string=0x27b9520 "CREATE_REPLICATION_SLOT \"sub_17264_sync_17251\" TEMPORARY LOGICAL pgoutput USE_SNAPSHOT") at walsender.c:1511 #12 0x0088eb44 in PostgresMain (argc=1, argv=0x275b738, dbname=0x275b578 "postgres", usernam

Re: [HACKERS] alter server for foreign table

On Sep 30, 2017, at 10:58 PM, Andrew Dunstan wrote: > > > On 09/30/2017 05:14 AM, Derry Hamilton wrote: >> Just to say, yes, this would be handy. I've been using a variant of >> that hack on reporting servers, while migrating systems from >> proprietary databases. It behaves quite gracefully

Re: [HACKERS] pg_prepared_xact_status

On Sep 29, 2017, at 11:33 PM, Robert Haas wrote: > On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer wrote: >> This sounds kind-of like 1/4 of a distributed transaction resolver, without >> a way to make it reliable enough to build the other 3/4. >> >> To make this practical

[HACKERS] alter server for foreign table

/may-i-alter-server-for-foreign-table I wonder how safe it is and if it is so simple, why it is not support in ALTER FOREIGN TABLE statement? Thanks in advance, -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] pg_prepared_xact_status

On 29.09.2017 11:27, Craig Ringer wrote: On 29 September 2017 at 15:57, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: So you are saying that Postgresql 2PC mechanism is not complete and user needs to maintain some extra informa

Re: [HACKERS] Index expression syntax

On 29.09.2017 11:03, Marko Tiikkaja wrote: On Fri, Sep 29, 2017 at 9:31 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: I wonder why syntax error is produced in this case: postgres=# create index metaindex on foo u

Re: [HACKERS] pg_prepared_xact_status

On 29.09.2017 06:02, Michael Paquier wrote: On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: In Postgres 10 we have txid_status function which returns status of transaction by XID. I wonder if it will be also useful to have similar function f

[HACKERS] Index expression syntax

s the form of a function call. -- So documentations states that sometimes it is possible to avoid parentheses, but it is unclear why I have to use double parentheses... I think that either grammar should be fixed, either documentation should be updated. /||/ -- Konstantin Knizhni

Re: [HACKERS] Surjective functional indexes

not actually affect any index. But certainly different attributes may have different probability of been updated. Unfortunately we do not know before check which attribute of JSON field (or any other fields used in indexed expression) is changed. -- Konstantin Knizhnik Postgres Professional:

[HACKERS] pg_prepared_xact_status

GetSystemIdentifier() to identify coordinator's node) and XID of coordinator's transaction. In this case we can use txid_status() to check status of transaction at coordinator. It eliminates need to scan WAL to determine status of prepared transaction. -- Konstantin Knizhnik Postgres Professional: http

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

? -- Konstantin Knizhnik 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] Surjective functional indexes

ex option explicitly set by user. This setting overrides 1) and 2) -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 83ee7d3..52189ac 100644 --

Re: [HACKERS] Surjective functional indexes

te of time. We can guess it from autotune, but such decision may be wrong (just because of application business logic). Postgres indexes already have a lot of options. And I think that "projection" option (or whatever we name it) is also needed. -- Konstantin Knizhnik Postgres Profession

Re: [HACKERS] Surjective functional indexes

On 14.09.2017 13:19, Simon Riggs wrote: On 14 September 2017 at 10:42, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: On 13.09.2017 14:00, Simon Riggs wrote: On 13 September 2017 at 11:30, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: The only r

Re: [HACKERS] Surjective functional indexes

On 13.09.2017 14:00, Simon Riggs wrote: On 13 September 2017 at 11:30, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: The only reason of all this discussion about terms is that I need to choose name for correspondent index option. Simon think that we do not need this option

Re: [HACKERS] Surjective functional indexes

On 13.09.2017 14:00, Simon Riggs wrote: On 13 September 2017 at 11:30, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: The only reason of all this discussion about terms is that I need to choose name for correspondent index option. Simon think that we do not need this option

Re: [HACKERS] Surjective functional indexes

On 13.09.2017 13:14, Christoph Berg wrote: Re: Konstantin Knizhnik 2017-09-13 <2393c4b3-2ec4-dc68-4ea9-670597b56...@postgrespro.ru> On 13.09.2017 10:51, Christoph Berg wrote: Re: Konstantin Knizhnik 2017-09-01 <f530ede0-1bf6-879c-c362-34325514f...@postgrespro.ru> + Func

Re: [HACKERS] Surjective functional indexes

On 13.09.2017 10:51, Christoph Berg wrote: Re: Konstantin Knizhnik 2017-09-01 <f530ede0-1bf6-879c-c362-34325514f...@postgrespro.ru> + Functional index is based on on projection function: function which extract subset of its argument. + In mathematic such functions are call

Re: [HACKERS] Surjective functional indexes

On 12.09.2017 19:28, Simon Riggs wrote: On 1 September 2017 at 09:47, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: On 01.09.2017 09:25, Simon Riggs wrote: On 1 September 2017 at 05:40, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: On Fri, Jun 9, 2017 at 8:08 PM

Re: [HACKERS] Cached plans and statement generalization

On 11.09.2017 12:24, Konstantin Knizhnik wrote: Attached please find rebased version of the patch. There are the updated performance results (pgbench -s 100 -c 1): protocol (-M) read-write read-only (-S) simple 3327 19325 extended 2256 16908

Re: [HACKERS] Cached plans and statement generalization

On 09.09.2017 06:35, Thomas Munro wrote: On Fri, May 26, 2017 at 3:54 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Attached please find rebased version of the autoprepare patch based on Tom's proposal (perform analyze for tree with constant literals and then replac

Re: [HACKERS] Secondary index access optimizations

On 07.09.2017 13:00, Thomas Munro wrote: On Sun, Sep 3, 2017 at 4:34 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Thank you for review. I attached new version of the patch with remove_restrictions_implied_by_constraints() function. Concerning failed tests - this is ac

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

mostly null values). -- Konstantin Knizhnik 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] Secondary index access optimizations

from logdate) = 3; select * from measurement where logdate between '2006-03-01' AND '2006-03-31'; select * from measurement where logdate >= '2006-03-01' AND logdate < '2006-04-01'; Right now only for the last query optimal query plan will be constructed. Unfortunately my patch is not cov

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

the following branch else if (att->attnotnull) seems to be not related to this branch, because in this case attcuralign is expected to be less then zero wjhich means that previous attribute is varlen field. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russia

Re: [HACKERS] Secondary index access optimizations

On 04.09.2017 12:59, Amit Langote wrote: Hi Konstantin, On 2017/09/04 18:19, Konstantin Knizhnik wrote: On 04.09.2017 05:38, Amit Langote wrote: On 2017/09/02 12:44, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: po

Re: [HACKERS] Secondary index access optimizations

On 04.09.2017 05:38, Amit Langote wrote: On 2017/09/02 12:44, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: postgres=# explain select * from bt where k between 1 and 2 and v = 100; QUER

Re: [HACKERS] JIT & function naming

), replace all non-alphanumeric characters spaces with '_' and take first N (16?) characters of the result? It seems to me that in most cases it will help to identify the query... -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via

Re: [HACKERS] Secondary index access optimizations

On 09/02/2017 06:44 AM, Thomas Munro wrote: On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: postgres=# explain select * from bt where k between 1 and 2 and v = 100; QUER

Re: [HACKERS] Surjective functional indexes

On 01.09.2017 09:25, Simon Riggs wrote: On 1 September 2017 at 05:40, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Attached please find rebased version of the patch. Now "proj

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

On 22.08.2017 17:27, Konstantin Knizhnik wrote: On 18.08.2017 04:33, Robert Haas wrote: It seems like a somewhat ad-hoc approach; it supposes that we can take any query produced by deparseSelectStmtForRel() and stick a LIMIT clause onto the very end and all will be well. Maybe that's

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

all and non-invasive. And in principle, it can be used not only postgres_fdw, but also in other FDW implementations to push down information about LIMIT. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

;u" values can be done without sorting, so times are similar. But in case of sorting by "v", pushing down limit allows to use TOP-1 instead of global sort and it reduces query execution time more than 2 times. -- Konstantin Knizhnik Postgres Professional: http://www.postgres

Re: [HACKERS] Secondary index access optimizations

On 14.08.2017 19:33, Konstantin Knizhnik wrote: On 14.08.2017 12:37, Konstantin Knizhnik wrote: Hi hackers, I am trying to compare different ways of optimizing work with huge append-only tables in PostgreSQL where primary key is something like timestamp and queries are usually accessing

Re: [HACKERS] Secondary index access optimizations

On 14.08.2017 12:37, Konstantin Knizhnik wrote: Hi hackers, I am trying to compare different ways of optimizing work with huge append-only tables in PostgreSQL where primary key is something like timestamp and queries are usually accessing most recent data using some secondary keys. Size

[HACKERS] Secondary index access optimizations

dexes if specified interval is covered by their conditions. I wonder if someone is familiar with this part of optimizer ad can easily fix it. Otherwise I am going to spend some time on solving this problems (if community think that such optimizations will be useful). -- Konstantin Knizhnik Postgres P

Re: [HACKERS] Error : undefined symbol : LWLockAssign in 9.6.3

anymore or doesn't concern about imcs module or are there any ways to run postgresql in memory only? Hi, I am author of IMCS module and performing support of it. Please contact to me directly. I have committed patch in https://github.com/knizhnik/imcs.git repository which allows to use IMCS

Re: [HACKERS] ASOF join

k that nobody will be interested in non-standard SQL extensions? -- Konstantin Knizhnik 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] ASOF join

On 16.06.2017 19:07, David Fetter wrote: On Fri, Jun 16, 2017 at 11:51:34AM +1200, Thomas Munro wrote: On Fri, Jun 16, 2017 at 4:20 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: I wonder if there were some discussion/attempts to add ASOF join to Postgres (sorr

Re: [HACKERS] WIP: Data at rest encryption

ow user to make choice whether to encrypt temporary data or not. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/storage/file/Makefile b/src/backend/storage/file/Makefile index d2198f2..9492662 100644 --- a/src/backend/s

[HACKERS] ASOF join

ym,time); It seems to me that adding ASOF joins should not require huge amount of work and can be done with minimal number of changes in executor and optimizer. But may be there are some problems/challenges which I do not realize now? -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro

Re: [HACKERS] Surjective functional indexes

Attached please find rebased version of the patch. Now "projection" attribute is used instead of surjective/injective. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/sr

Re: [HACKERS] Proposal : For Auto-Prewarm.

as I understand pg_autoprewarm has all necessary infrastructure to do parallel load. We just need to spawn more than one background worker and specify separate block range for each worker. Do you think that such functionality (parallel autoprewarm) can be useful and be easily added? -- Konstantin K

Re: [HACKERS] Surjective functional indexes

ined using "surjection" term:) Christoph -- Konstantin Knizhnik 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] Surjective functional indexes

On 05/27/2017 09:50 PM, Peter Eisentraut wrote: On 5/25/17 12:30, Konstantin Knizhnik wrote: Functions like (info->>'name') are named "surjective" ni mathematics. A surjective function is one where each value in the output type can be obtained by some input value. Tha

[HACKERS] Logical replication & corrupted pages recovery

seems to be much more challenged task. If somebody has already thought about this problem, have some plan or may be even ready solution for it, please share your thoughts. Thanks in advance, -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Surjective functional indexes

On 25.05.2017 19:37, Tom Lane wrote: Konstantin Knizhnik <k.knizh...@postgrespro.ru> writes: My proposal is to check value of function for functional indexes instead of just comparing set of effected attributes. Obviously, for some complex functions it may have negative effect on

[HACKERS] Surjective functional indexes

o explicitly disable it and make decision weather index needs to be updated or not only based on set of effected attributes. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/commo

Re: [HACKERS] Cached plans and statement generalization

On 10.05.2017 19:11, Konstantin Knizhnik wrote: Based on the Robert's feedback and Tom's proposal I have implemented two new versions of autoprepare patch. First version is just refactoring of my original implementation: I have extracted common code into prepare_cached_plan

Re: [HACKERS] Cached plans and statement generalization

On 15.05.2017 18:31, Robert Haas wrote: On Wed, May 10, 2017 at 12:11 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: Robert, can you please explain why using TRY/CATCH is not safe here: This is definitely not a safe way of using TRY/CATCH. This has been discussed many

Re: [HACKERS] Cached plans and statement generalization

On 12.05.2017 18:23, Bruce Momjian wrote: On Fri, May 12, 2017 at 10:50:41AM +0300, Konstantin Knizhnik wrote: Definitely changing session context (search_path, date/time format, ...) may cause incorrect behavior of cached statements. I wonder if we should clear the cache whenever any SET

Re: [HACKERS] Cached plans and statement generalization

On 12.05.2017 03:58, Bruce Momjian wrote: On Thu, May 11, 2017 at 10:41:45PM +0300, Konstantin Knizhnik wrote: This is why I have provided second implementation which replace literals with parameters after raw parsing. Certainly it is slower than first approach. But still provide significant

Re: [HACKERS] Cached plans and statement generalization

On 05/11/2017 10:52 PM, Andres Freund wrote: On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote: On 05/11/2017 09:31 PM, Tom Lane wrote: Bruce Momjian <br...@momjian.us> writes: Good point. I think we need to do some measurements to see if the parser-only stage is actually signi

Re: [HACKERS] Cached plans and statement generalization

tantin Knizhnik 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] Cached plans and statement generalization

On 05/11/2017 06:12 PM, Bruce Momjian wrote: On Wed, May 10, 2017 at 07:11:07PM +0300, Konstantin Knizhnik wrote: I am going to continue work on this patch I will be glad to receive any feedback and suggestions for its improvement. In most cases, applications are not accessing Postgres directly

Re: [HACKERS] Cached plans and statement generalization

, but definitely much more invasive and harder to implement. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c index 6e52eb7..f2eb0f5 100644 --- a/src/backend/nodes/nodeFuncs.c

Re: [HACKERS] Why type coercion is not performed for parameters?

ave to set UNKNOWNOID type otherwise a lot of queries will not work. .m -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

[HACKERS] Why type coercion is not performed for parameters?

ail functions solves the problem and doesn't cause some new issues: all regression tests are passed. So my question is whether it is possible to use the same rule for type coercion of parameters as for constant? -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Rus

Re: [HACKERS] Bug in prepared statement cache invalidation?

invalidation of all functions in case of DDL seems to be more acceptable solution. -- Konstantin Knizhnik 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

Re: [HACKERS] Bug in prepared statement cache invalidation?

l PL implementations. Looks like no easy fix is possible here. I am not sure how critical is this problem. Definitely it rarely happens, but lack of normal workarounds (restart backend, recreate function?) seems to be disappointing. -- Konstantin Knizhnik Postgres Professional: http://www.postgre

Re: [HACKERS] Cached plans and statement generalization

On 01.05.2017 18:52, Robert Haas wrote: On Fri, Apr 28, 2017 at 6:01 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: Any comments and suggestions for future improvement of this patch are welcome. +

Re: [HACKERS] Cached plans and statement generalization

of this patch are welcome. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c index cd39167..4fbc8b7 100644 --- a/src/backend/nodes/nodeFuncs.c +++ b/src/backend/nodes/nodeFuncs.c

[HACKERS] Bug in prepared statement cache invalidation?

-- Konstantin Knizhnik 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] Cached plans and statement generalization

that might not be too bad. But this is getting off topic - I just wanted to capture the idea while it was rumbling around. I think that it will be enough to handle modification of search path and invalidate prepared statements cache in this case. -- Konstantin Knizhnik Postgres Professional

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 10:49, Konstantin Knizhnik wrote: On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering some upper limit on the number of prepared statements? In this case we need some kind of LRU for maintaining cache of autoprepared statements. I think that it is good idea

Re: [HACKERS] Cached plans and statement generalization

On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Konstantin Knizhnik Well, first of all I want to share results I already get: pgbench with default parameters, scale 10 and one connection: So

Re: [HACKERS] Cached plans and statement generalization

oned, the same problem can be reproduced with explicitly prepared statements. Greetings, Andres Freund -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Cached plans and statement generalization

and are invalidated by PlanCacheRelCallback. - Andres -- Konstantin Knizhnik 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] Cached plans and statement generalization

On 04/25/2017 11:40 PM, Serge Rielau wrote: On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: SELECT ‘hello’::CHAR(10) || ‘World’, 5 + 6; You can substitute ‘hello’, ‘World’, 5, and 6. But not 10. I am

Re: [HACKERS] Cached plans and statement generalization

On 04/25/2017 08:09 PM, Serge Rielau wrote: On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: On 25.04.2017 19:12, Serge Rielau wrote: On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <ma

Re: [HACKERS] Cached plans and statement generalization

On 04/25/2017 07:54 PM, David Fetter wrote: On Tue, Apr 25, 2017 at 06:11:09PM +0300, Konstantin Knizhnik wrote: On 24.04.2017 21:43, Andres Freund wrote: Hi, On 2017-04-24 11:46:02 +0300, Konstantin Knizhnik wrote: So what I am thinking now is implicit query caching. If the same query

Re: [HACKERS] Cached plans and statement generalization

On 25.04.2017 19:12, Serge Rielau wrote: On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: Another problem is caused by using integer literals in context where parameters can not be used, for example "

Re: [HACKERS] Cached plans and statement generalization

On 24.04.2017 21:43, Andres Freund wrote: Hi, On 2017-04-24 11:46:02 +0300, Konstantin Knizhnik wrote: So what I am thinking now is implicit query caching. If the same query with different literal values is repeated many times, then we can try to generalize this query and replace

Re: [HACKERS] Cached plans and statement generalization

On 24.04.2017 13:24, Alexander Korotkov wrote: Hi, Konstantin! On Mon, Apr 24, 2017 at 11:46 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru <mailto:k.knizh...@postgrespro.ru>> wrote: There were a lot of discussions about query plan caching in hackers mailing list,

[HACKERS] Cached plans and statement generalization

if such option was already considered and if it was for some reasons rejected: can you point me at this reasons? -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] FDW and parallel execution

On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote: Hi, At Sun, 02 Apr 2017 16:30:24 +0300, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote in <58e0fcf0.2070...@postgrespro.ru> Hi hackers and personally Robet (you are the best expert in both areas). I want to ask one m

[HACKERS] FDW and parallel execution

cost=32605.64..32605.64 rows=1500032 width=8) -> Foreign Scan on customer_fdw (cost=0.00..32605.64 rows=1500032 width=8) The plans look very similar, but first one is parallel and second - not. My FDW provides implementation for IsForeignScanParallelSafe which returns tru

Re: [HACKERS] Parallel query execution with SPI

On 31.03.2017 13:48, Robert Haas wrote: On Fri, Mar 31, 2017 at 3:33 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: It is possible to execute query concurrently using SPI? If so, how it can be enforced? I tried to open cursor with CURSOR_OPT_PARALLEL_OK flag but it doesn'

[HACKERS] Parallel query execution with SPI

->portal = SPI_cursor_open_with_args(NULL, fsstate->query, fsstate->numParams, argtypes, values, nulls, true, CURSOR_OPT_PARALLEL_OK); ... SPI_cursor_fetch(fsstate->portal, true, 1); Thanks in advance, -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com

Re: [HACKERS] WIP: Faster Expression Processing v4

Your patch 6420 ms 1034 ms VOPS 396 ms 249 ms VOPS + patch367 ms 233 ms -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

[HACKERS] Two questions about Postgres parser

::float8) from foo; select coalesce(c, 0.0::float8::complex) from foo; coalesce -- (0 rows) -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] VOPS: vectorized executor for Postgres: how to speedup OLAP queries more than 10 times without changing anything in Postgres executor

een 0.08 and 0.1 and l_quantity < 24; On 13.02.2017 17:12, Konstantin Knizhnik wrote: Hello hackers, There were many discussions concerning possible ways of speeding-up Postgres. Different approaches were suggested: - JIT (now we have three different prototype implementations based on

Re: [HACKERS] Sum aggregate calculation for single precsion real

On 14.02.2017 16:59, Jim Nasby wrote: On 2/13/17 10:45 AM, Konstantin Knizhnik wrote: It is not true - please notice query execution time of this two queries: I bet you'd get even less difference if you simply cast to float8 instead of adding 0.0. Same result, no floating point addition

  1   2   3   >