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
d approach is 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 R
-> 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
estions about the 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
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-hackers@postgresql.org)
To make changes to
On 11/06/2017 04:27 AM, Thomas Munro wrote:
On Fri, Sep 8, 2017 at 3:58 AM, Konstantin Knizhnik
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 <= '2017-03-31') from (logdate
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
On 12.10.2017 04:23, Craig Ringer wrote:
On 12 October 2017 at 00:57, Konstantin Knizhnik
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. Though I wouldn't expect any
On 11.10.2017 10:07, Craig Ringer wrote:
On 9 October 2017 at 15:37, Konstantin Knizhnik
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, making it very clear when thing
tgres:
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
rarely 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:/
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
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 p
at logical 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.postgr
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 sender.
"shardman_copy_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 0x00
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", u
4
#11 0x008246ee 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", u
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 w
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 I think you'd need a wa
/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
On 29.09.2017 11:27, Craig Ringer wrote:
On 29 September 2017 at 15:57, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
So you are saying that Postgresql 2PC mechanism is not complete
and user needs to maintain some extra information to make it work?
No, it pr
On 29.09.2017 11:03, Marko Tiikkaja wrote:
On Fri, Sep 29, 2017 at 9:31 AM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
I wonder why syntax error is produced in this case:
postgres=# create index metaindex on foo using
gin(to_tsvector('english',
On 29.09.2017 06:02, Michael Paquier wrote:
On Fri, Sep 29, 2017 at 1:53 AM, Konstantin Knizhnik
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 for 2PC
transactions which can operate
entheses can be omitted if the
expression has 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 documentatio
hema design it is possible to expect that most
of updates are hot updates: do 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
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 Professi
tinue review of this code?
--
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
ction" index 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..52
r it will perform projection or not
and whether comparing old/new expression value makes sense or is just
waste 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 "
On 14.09.2017 13:19, Simon Riggs wrote:
On 14 September 2017 at 10:42, Konstantin Knizhnik
wrote:
On 13.09.2017 14:00, Simon Riggs wrote:
On 13 September 2017 at 11:30, Konstantin Knizhnik
wrote:
The only reason of all this discussion about terms is that I need to
choose
name for
On 13.09.2017 14:00, Simon Riggs wrote:
On 13 September 2017 at 11:30, Konstantin Knizhnik
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 at all. In this case we should
not
On 13.09.2017 14:00, Simon Riggs wrote:
On 13 September 2017 at 11:30, Konstantin Knizhnik
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 at all. In this case we should
not
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
+ Functional index is based on on projection function: function
On 13.09.2017 10:51, Christoph Berg wrote:
Re: Konstantin Knizhnik 2017-09-01
+ Functional index is based on on projection function: function which
extract subset of its argument.
+ In mathematic such functions are called non-injective. For injective
function if any attribute
On 12.09.2017 19:28, Simon Riggs wrote:
On 1 September 2017 at 09:47, Konstantin Knizhnik
wrote:
On 01.09.2017 09:25, Simon Riggs wrote:
On 1 September 2017 at 05:40, Thomas Munro
wrote:
On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
wrote:
Attached please find rebased version of
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
On 09.09.2017 06:35, Thomas Munro wrote:
On Fri, May 26, 2017 at 3:54 AM, Konstantin Knizhnik
wrote:
Attached please find rebased version of the autoprepare patch based on Tom's
proposal (perform analyze for tree with constant literals and then replace
them with parameters).
Also I subm
On 07.09.2017 13:00, Thomas Munro wrote:
On Sun, Sep 3, 2017 at 4:34 AM, Konstantin Knizhnik
wrote:
Thank you for review.
I attached new version of the patch with
remove_restrictions_implied_by_constraints() function.
Concerning failed tests - this is actually result of this optimization
values, either
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
easurement where extract(month 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 opt
uot;alignto" and comment in 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: ht
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
wrote:
postgres=# explain select * from bt where
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
wrote:
postgres=# explain select * from bt where k between 1 and 2 and v = 100;
QUERY PLAN
text (es_sourceText from EText), 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
On 09/02/2017 06:44 AM, Thomas Munro wrote:
On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik
wrote:
postgres=# explain select * from bt where k between 1 and 2 and v = 100;
QUERY PLAN
On 01.09.2017 09:25, Simon Riggs wrote:
On 1 September 2017 at 05:40, Thomas Munro
wrote:
On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik
wrote:
Attached please find rebased version of the patch.
Now "projection" attribute is used instead of surjective/injective.
Hi Konstan
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&#
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
er by v limit 1
100 42
There is index for "u", so fetching records with smallest "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
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
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
s 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
cs
module 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 t
e join instead of nested loop) but also
simplifying writing of such queries. Or do you think 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
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
wrote:
I wonder if there were some discussion/attempts to add ASOF join to Postgres
(sorry, may be there is better term for it, I am
is
better to allow 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
Trades ASOF JOIN EqTrades USING (underlyingSym,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 Kniz
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
astructure 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 Knizhnik
Postgres Professional: http://www.po
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
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
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
On 25.05.2017 19:37, Tom Lane wrote:
Konstantin Knizhnik 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
update speed.
This is why I have added
is possible to 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/
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_cache
On 15.05.2017 18:31, Robert Haas wrote:
On Wed, May 10, 2017 at 12:11 PM, Konstantin Knizhnik
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, many times on this mailing list
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
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
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 writes:
Good point. I think we need to do some measurements to see if the
parser-only stage is actually significant. I have a hunch
lane
Yes, my results shows that pg_parse_query adds not so much overhead:
206k TPS for my first variant with string literal substitution and modified
query text used as hash key vs.
181k. TPS for version with patching raw parse tree constructed by
pg_parse_query.
--
Konstantin Knizhnik
Pos
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
be it is even more
perspective approach, 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..f2eb0
iteral I have 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
tions.
The fix in func_get_detail 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:
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
ot of changes, in all 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
On 01.05.2017 18:52, Robert Haas wrote:
On Fri, Apr 28, 2017 at 6:01 AM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Any comments and suggestions for future improvement of this patch
are welcome.
+PG_TRY();
+{
+
nt 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/n
ERY
p
--
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
during CREATE processing though, so 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.
--
Konsta
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
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
ched plans?
As I already mentioned, 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 lis
nction 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
On 04/25/2017 11:40 PM, Serge Rielau wrote:
On Apr 25, 2017, at 1:37 PM, Konstantin Knizhnik 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 substituting only string literals.
On 04/25/2017 08:09 PM, Serge Rielau wrote:
On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik
wrote:
On 25.04.2017 19:12, Serge Rielau wrote:
On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik mailto:k.knizh...@postgrespro.ru>> wrote:
Another problem is
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 with
On 25.04.2017 19:12, Serge Rielau wrote:
On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Another problem is caused by using integer literals in context where
parameters can not be used, for example "order by 1”.
You will also need t
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 it with
On 24.04.2017 13:24, Alexander Korotkov wrote:
Hi, Konstantin!
On Mon, Apr 24, 2017 at 11:46 AM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
There were a lot of discussions about query plan caching in
hackers mailing list, but I failed to find some clear
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
On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote:
Hi,
At Sun, 02 Apr 2017 16:30:24 +0300, Konstantin Knizhnik
wrote in <58e0fcf0.2070...@postgrespro.ru>
Hi hackers and personally Robet (you are the best expert in both
areas).
I want to ask one more question concerning parallel executi
76 rows=2284376 width=8)
-> Hash (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 im
On 31.03.2017 13:48, Robert Haas wrote:
On Fri, Mar 31, 2017 at 3:33 AM, Konstantin Knizhnik
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't help:
query is executed by s
state->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.postgrespr
1171 ms
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
::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
and '1997-01-01'::date
and l_discount between 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:
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 add
1 - 100 of 259 matches
Mail list logo
