and thank you for your comments :)
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1707121142300.12795%40lancre
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
://www.postgresql.org/message-id/alpine.DEB.2.20.1707121338090.12795%40lancre
[2]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1707121142300.12795%40lancre
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom 0ee372e93b8d7017563d2f2f55357c39c08a Mon Sep
o check that there's no a
performance degradation on them too.
[1]
https://www.postgresql.org/message-id/ba261b9fc25dea4069d8ba9a8fcadf35%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing
came from this or that, so I would let
that out.
For log and aggregated log possibly that would make more sense, but it
must stay easy to parse.
Ok!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql
Ok, fine. My point was just to check before proceeding.
And I'm very grateful for that :)
--
Marina Polyakova
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
container structure of the
variables is different, so I think that the answer is no.
--
Marina Polyakova
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 subscrip
es are
not "default" (= no failures and no retries)?
--
Marina Polyakova
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
n the list. How do you
think, is it a good idea to name a variables structure in pgbench in the
same way (VariableSpace) or it should be different not to be confused
(Variables, for example)?
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
-
hange it
and write the appropriate note in documentation.
--
Marina Polyakova
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
ybe having a clean "Variables" data structure could help improve the
situation.
Ok!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ee
in the output of the program? Of course now failures are special cases
because they disconnect its clients to the end of the program and ruin
all the results. I hope that if this patch is committed there will be
much more cases with retried failures.
If a transaction is skipped, there was no tries
]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1707031321370.3419%40lancre
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom 58f51cdc896af801bcd35e495406655ca03aa6ce Mon Sep 17 00:00:00 2001
From: Marina Polyakova <m.pol
o the various existing reports unconditionnaly (i.e.
without a new option), so maybe no new option would be needed.
Thanks! I didn't think about it in this way..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list
option I'll
do it.
About 0004:
The documentation must not be in a separate patch, but in the same
patch as their corresponding code.
Ok!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
> To be clear, part of "retrying from the beginning" means that if a> result from one statement is used to determine the content (or> whether to run) a subsequent statement, that first statement must be> run in the new transaction and the results evaluated again to> determine what to use for the
g
whether this is a good idea, or would we prefer that failing
transactions are retried.
Yes, I have meant this, thank you!
I think it's pretty obvious that transactions that failed with
some serializability problem should be retried.
Thank you voted :)
--
Marina Polyakova
Pos
whether this is a good idea, or would we prefer that failing
transactions are retried.
And thank you very much for your explanation how and why transactions
with failures should be retried! I'll try to implement all of it.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
te is asking
whether this is a good idea, or would we prefer that failing
transactions are retried.
With his explanation has my text become clearer?
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pg
Sounds like a good idea.
Thank you!
Please add to the next CommitFest
Done: https://commitfest.postgresql.org/14/1170/
and review
somebody else's patch in exchange for having your own patch reviewed.
Of course, I remember about it.
--
Marina Polyakova
Postgres Professional: http
://www.postgresql.org/docs/10/static/xfunc-volatility.html
[2] https://www.postgresql.org/docs/10/static/sql-createfunction.html
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Here's v2 of the patches. Changes from v1:
And here there's v3 of planning and execution: common executor steps for
all types of cached expression.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom 5e89221251670526eb2b5750868ac73eee48f10b
that there is no obvious performance degradation on regular
queries (according to pgbench).
Thanks for testing it, I'll try not to forget about it next time =[
In short, it looks very promising.
And thanks again!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian
'costs', which includes cost changes for cached expressions
(according to their behaviour).
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom cf446cbfc8625701f9e3f32d1870b47de869802a Mon Sep 17 00:00:00 2001
From: Marina Polyakova <
%40postgrespro.ru#98c77534fa51aa4bf84a5b39931c4...@postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom d7871c9aaf64210130b591a93c13b18c74ebb2b4 Mon Sep 17 00:00:00 2001
From: Marina Polyakova <m.polyak...@postgrespro.ru>
Date: Wed,
Sorry, attached patch.
Исходное сообщение
Тема: WIP Patch: Precalculate stable functions
Дата: 20-04-2017 19:56
От: Marina Polyakova <m.polyak...@postgrespro.ru>
Кому: pgsql-hackers@postgresql.org
Hello everyone!
Now in Postgresql only immutable functions are precalc
LL (array)" which use
nonvolatile operators;
- precalculation of row compare expressions which use nonvolatile
operators.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
+7 926 92 00 265
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
26 matches
Mail list logo
