út 21. 5. 2019 v 9:04 odesílatel Corey Huinker
napsal:
>
>>> Is there anything preventing us from having the planner resolve object
>>> names from strings?
>>>
>>
>> The basic problem is fact so when you use PREPARE, EXECUTE protocol, you
>> has not parameters in planning time.
>>
>
> I agree tha
Hi
čt 9. 5. 2019 v 6:34 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebased patch
>
rebase after pgindent
Regards
Pavel
>
> Regards
>
> Pavel
>
>
>
schema-variables-20190524.patch.gz
Description: application/gzip
Hi
út 5. 3. 2019 v 18:37 odesílatel Pavel Stehule
napsal:
>
>
> út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal:
>
>> David Steele writes:
>> > This thread has been very quiet for a month. I agree with Andres [1]
>> > that we should push this to PG1
st 29. 5. 2019 v 17:49 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> Rebase after pg_indent. Besides, off the list there was a suggestion that
> this
> could be useful to accept more than one data type as a key for
> subscripting.
> E.g. for jsonb it probably makes sense to understand
st 3. 10. 2018 v 1:01 odesílatel Thomas Munro
napsal:
> On Sun, Sep 30, 2018 at 11:20 AM Pavel Stehule
> wrote:
> > I hope so now, there are almost complete functionality. Please, check it.
>
> Hi Pavel,
>
> FYI there is a regression test failure on Windows
pá 5. 10. 2018 v 7:57 odesílatel Michael Paquier
napsal:
> On Thu, Oct 04, 2018 at 05:18:07PM +0900, Michael Paquier wrote:
> > So it seems that I am clearly outvoted here ;)
> >
> > Okay, let's do as you folks propose.
>
> And attached is a newer version with this isleaf stuff and the previous
>
so 6. 10. 2018 v 13:47 odesílatel Amit Kapila
napsal:
> On Sat, Oct 6, 2018 at 2:55 AM Tom Lane wrote:
> >
> > My initial thought was that we should just re-mark
> transaction_timestamp()
> > as parallel-restricted and call it a day, but we'd then have to do the
> > same for SQLValueFunction, wh
Hi
ne 30. 9. 2018 v 0:19 odesílatel Pavel Stehule
napsal:
>
>
> so 29. 9. 2018 v 10:34 odesílatel Pavel Stehule
> napsal:
>
>>
>>
>> so 22. 9. 2018 v 8:00 odesílatel Pavel Stehule
>> napsal:
>>
>>> Hi
>>>
>>> rebased ag
Hi
I configured PostgreSQL without JIT support, but JIT is active by default
postgres=# show jit;
┌─┐
│ jit │
╞═╡
│ on │
└─┘
(1 row)
Unfortunately - this combination does crashes on some bigger queries.
Regards
Pavel
po 8. 10. 2018 v 12:06 odesílatel Thomas Munro <
thomas.mu...@enterprisedb.com> napsal:
> On Mon, Oct 8, 2018 at 10:52 PM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I configured PostgreSQL without JIT support, but JIT is active by default
>
> I think t
Hi
I try to understand to a issue
https://stackoverflow.com/questions/52685384/subquery-performance-on-simple-case
The user sent a plan:
QUERY PLAN
Merge Semi Join (cost=82.97..580.24 rows=580 width=8) (actual
time=0.503..9557.396 rows=721 loops=1)
Merge Cond: (tips.users_id = follows.users_i
po 8. 10. 2018 v 16:58 odesílatel Andres Freund napsal:
> Hi
>
> On October 8, 2018 2:51:15 AM PDT, Pavel Stehule
> wrote:
> >Hi
> >
> >I configured PostgreSQL without JIT support, but JIT is active by
> >default
> >
> >postgres=# sh
po 8. 10. 2018 v 17:10 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
> >Andres Freund writes:
> >> Where is the jit=on coming from? Config from before it was turned
> >off?
> >
> >A look in guc.c shows that jit defaults to "on" whether or not JIT is
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi
I tested this patch. This patch removes some duplicate ro
po 8. 10. 2018 v 17:22 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 8:16:06 AM PDT, Pavel Stehule
> wrote:
> >po 8. 10. 2018 v 17:10 odesílatel Andres Freund
> >napsal:
> >
> >>
> >>
> >> On October 8, 2018 8:03:5
po 8. 10. 2018 v 17:59 odesílatel Andres Freund napsal:
> Hi,
>
> On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
> > >> A look in guc.c shows that jit defaults to "on" whether or not JIT is
> > >> enabled at compi
po 8. 10. 2018 v 19:24 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 10:16:54 AM PDT, Pavel Stehule
> wrote:
> >po 8. 10. 2018 v 17:59 odesílatel Andres Freund
> >napsal:
> >
> >> Hi,
> >>
> >> On 2018-10-08 11:43:42 -0400,
>
> >I am thinking so simple number should be good enough. We can require
> >equality - Just I need a signal so some is wrong - better than Postgres
> >crash.
>
> It'd cause constant conflicts and / or we would regularly forget updating
> it. It's not that trivial to determine what influences ABI c
po 8. 10. 2018 v 17:00 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > The user sent a plan:
>
> > QUERY PLAN
> > Merge Semi Join (cost=82.97..580.24 rows=580 width=8) (actual
> > time=0.503..9557.396 rows=721 loops=1)
> > Merge Cond:
Hi
út 9. 10. 2018 v 5:28 odesílatel Michael Paquier
napsal:
> On Mon, Oct 08, 2018 at 03:22:55PM +0000, Pavel Stehule wrote:
> > I tested this patch. This patch removes some duplicate rows, what is
> > good - on second hand, after this patch, the textToQualifiedNameList
> &g
út 9. 10. 2018 v 13:20 odesílatel Michael Paquier
napsal:
> On Tue, Oct 09, 2018 at 10:47:48AM +0200, Pavel Stehule wrote:
> > The difference on 10M calls is about 300ms - it is about 6%.
>
> This number gives a good argument for rejecting this patch. I am not
> us
Hi
I tested last patch and I have some notes:
1.
postgres=# explain select distinct a1 from foo;
+---+
|QUERY PLAN
|
+
út 9. 10. 2018 v 15:59 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Tue, 9 Oct 2018 at 15:43, Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I tested last patch and I have some notes:
> >
> > 1.
> &g
út 9. 10. 2018 v 16:13 odesílatel Pavel Stehule
napsal:
>
>
> út 9. 10. 2018 v 15:59 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Tue, 9 Oct 2018 at 15:43, Pavel Stehule
>> wrote:
>> >
>> > Hi
>> &
Hi
ne 30. 9. 2018 v 8:23 odesílatel Pavel Stehule
napsal:
>
>
> ne 30. 9. 2018 v 0:21 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>
>> > On Fri, 20 Jul 2018 at 23:32, Dmitry Dolgov <9erthali...@gmail.com>
>> wrote:
>> >
>>
čt 11. 10. 2018 v 22:48 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, 10 Oct 2018 at 14:26, Pavel Stehule
> wrote:
> >
> > I am playing with this feature little bit
>
> Thanks a lot!
>
> > I have one idea - can be possible to use
Hi
ne 21. 10. 2018 v 21:47 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sun, Oct 21, 2018 at 12:11 PM Heikki Linnakangas
> wrote:
> > On 21/10/2018 21:17, Paul A Jungwirth wrote:
> > > 3. Build our own abstractions on top of ranges, and then use those to
> > > implem
Hi
út 23. 10. 2018 v 14:50 odesílatel Erik Rijkers napsal:
> > [schema-variables-20181007-01.patch.gz]
>
> Hi,
>
> I tried to test your schema-variables patch but got stuck here instead
> (after applying succesfully on top of e6f5d1acc):
>
> make[2]: *** No rule to make target
> '../../../src/in
čt 25. 10. 2018 v 17:09 odesílatel Alvaro Herrera
napsal:
> On 2018-Oct-25, Chapman Flack wrote:
>
> > On 10/25/18 10:39 AM, Tom Lane wrote:
> > > I think getting out from under libxml2's idiosyncrasies and security
> > > lapses would be great, but is there a plausible alternative out there?
> >
Hi
> But a roadmap that could lead to eventual availability of one of the
> C/C++ implementations would be nice too.
>
Somebody should to do some work and write patch :/. Although libxml2 is
after feature freeze - it is code widely used. The change of XML support
should be safe, because there ca
>
> XMLTABLE would be the headache. Using the standard name for something
> that ain't the standard function has not left any painless way that the
> standard function could be added. OTOH, it has only been in the wild
> since 10, so renaming it to something else (xpath_table?) will probably
> be m
pá 26. 10. 2018 v 6:25 odesílatel Chapman Flack
napsal:
> On 10/25/18 23:16, Pavel Stehule wrote:
> >> XMLTABLE would be the headache. Using the standard name for something
> >> that ain't the standard function has not left any painless way that the
> >> sta
Hi
I try to create operator + for varchar and integer with Oracle behave.
create or replace function sum(varchar, int)
returns int as $$ select $1::int + $2 $$ language sql;
create operator + (function = sum, leftarg = varchar, rightarg = int,
commutator = +);
create table foo2(a varchar);
inse
po 29. 10. 2018 v 7:35 odesílatel Fabien COELHO
napsal:
>
> Hello Pavel,
>
> > I try to create operator + for varchar and integer with Oracle behave.
> >
> > create or replace function sum(varchar, int)
> > returns int as $$ select $1::int + $2 $$ language sql;
> >
> > create operator + (function
Hi
čt 25. 10. 2018 v 21:47 odesílatel Alvaro Herrera
napsal:
> On 2018-Oct-25, Pavel Stehule wrote:
>
> > I am thinking so I can fix some issues related to XMLTABLE. Please, send
> me
> > more examples and test cases.
>
> Please see Markus Winand's patch that I r
>
I have a access to too old 11.2 Oracle. There I had to modify query
because there is not boolean type. I replaced bool by int, but I got a error
ORA-19224:XPTY-004 .. expected node()*, got xs:string - it doesn't work
with/without string() wrappings.
Regards
Pavel Stehule
po 29. 10. 2018 v 11:05 odesílatel Pavel Stehule
napsal:
>
> (It would not be exactly overloading, because of the special sugared
>>> syntax known to the parser, but it could look like overloading, and be
>>> intuitive to the user.)
>>>
>>> If you
po 29. 10. 2018 v 10:11 odesílatel Pavel Stehule
napsal:
> Hi
>
> čt 25. 10. 2018 v 21:47 odesílatel Alvaro Herrera <
> alvhe...@2ndquadrant.com> napsal:
>
>> On 2018-Oct-25, Pavel Stehule wrote:
>>
>> > I am thinking so I can fix some issues related
Hi
út 30. 10. 2018 v 7:52 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> Hi Mathias, Pavel,
>
> On 2018/08/17 12:26, Mathias Brossard wrote:
> > On Thu, Aug 16, 2018 at 12:46 AM Pavel Stehule
> >>
> >> This is question - maybe we can s
st 31. 10. 2018 v 3:27 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> On 2018/10/30 20:03, Pavel Stehule wrote:
> > út 30. 10. 2018 v 7:52 odesílatel Amit Langote <
> > langote_amit...@lab.ntt.co.jp> napsal:
> >> Could one of you please revi
Hi
I have report of one customer. Some scripts stopped on 11 because VACUUM
ANALYZE VERBOSE doesn't work now.
postgres=# vacuum analyze verbose;
ERROR: syntax error at or near "verbose"
LINE 1: vacuum analyze verbose;
^
vacuum verbose analyze is working.
Regards
Pavel
st 31. 10. 2018 v 8:34 odesílatel Sergei Kornilov napsal:
> Hi
>
> At least this is documented behavior:
> > When the option list is surrounded by parentheses, the options can be
> written in any order. Without parentheses, options must be specified in
> exactly the order shown above.
> https://w
st 31. 10. 2018 v 8:38 odesílatel Michael Paquier
napsal:
> On Wed, Oct 31, 2018 at 03:34:02PM +0900, Amit Langote wrote:
> > On 2018/10/31 15:30, Pavel Stehule wrote:
> >> I am not sure. Has not sense run this test over empty database, and some
> >> bigger da
st 31. 10. 2018 v 8:55 odesílatel Michael Paquier
napsal:
> On Wed, Oct 31, 2018 at 08:38:27AM +0100, Pavel Stehule wrote:
> > ok. Unfortunatelly it is not mentioned in release notes - in not
> compatible
> > changes.
> >
> > This change can hit lot of users. It
st 31. 10. 2018 v 7:34 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> On 2018/10/31 15:30, Pavel Stehule wrote:
> > st 31. 10. 2018 v 3:27 odesílatel Amit Langote <
> > langote_amit...@lab.ntt.co.jp> napsal:
> >> +appendPQExpBufferStr
Hi
The processing of named parameters inside CALL statement is not correct.
It is my code :-/. I am sorry
Attached patch fix it.
This still doesn't fix INOUT variables with default value - so is not fully
correct, but in this moment, it can show, where is a core of this issue.
Regards
Pavel
d
čt 1. 11. 2018 v 13:00 odesílatel Pavel Stehule
napsal:
> Hi
>
> The processing of named parameters inside CALL statement is not correct.
>
> It is my code :-/. I am sorry
>
> Attached patch fix it.
>
> This still doesn't fix INOUT variables with default value - s
čt 1. 11. 2018 v 13:10 odesílatel Pavel Stehule
napsal:
>
>
> čt 1. 11. 2018 v 13:00 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> The processing of named parameters inside CALL statement is not correct.
>>
>> It is my code :-/. I am sorry
Cleaned patch with regress tests
diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out
index 547ca22a55..8762e1335c 100644
--- a/src/pl/plpgsql/src/expected/plpgsql_call.out
+++ b/src/pl/plpgsql/src/expected/plpgsql_call.out
@@ -276,3 +276,43 @@ DR
čt 1. 11. 2018 v 14:31 odesílatel Pavel Stehule
napsal:
> Cleaned patch with regress tests
>
>
minor cleaning
Regards
Pavel
diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out
index 547ca22a55..8762e1335c 100644
--- a/src/pl/pl
pá 2. 11. 2018 v 3:57 odesílatel Corey Huinker
napsal:
> > Are you thinking something like having a COPY command that provides
>> > results in such a way that they could be referenced in a FROM clause
>> > (perhaps a COPY that defines a cursor…)?
>>
>> That would also be nice, but what I was thin
pá 2. 11. 2018 v 9:02 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 02/11/2018 06:04, Pavel Stehule wrote:
> > čt 1. 11. 2018 v 14:31 odesílatel Pavel Stehule > <mailto:pavel.steh...@gmail.com>> napsal:
> >
> > Cleaned pat
pá 2. 11. 2018 v 6:17 odesílatel Amit Langote
napsal:
> Hi,
>
> On 2018/11/01 2:19, Pavel Stehule wrote:
> > st 31. 10. 2018 v 7:34 odesílatel Amit Langote <
> > langote_amit...@lab.ntt.co.jp> napsal:
> >> On 2018/10/31 15:30, Pavel Stehule wrote:
> >
Hi
so 3. 11. 2018 v 22:47 odesílatel Tom Lane napsal:
> I wrote:
> > I'm going to go see about converting this to just call
> > expand_function_arguments and then drop all the special-case code.
>
> So while looking at that ... isn't the behavior for non-writable output
> parameters basically in
ne 4. 11. 2018 v 16:54 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > so 3. 11. 2018 v 22:47 odesílatel Tom Lane napsal:
> >> So while looking at that ... isn't the behavior for non-writable output
> >> parameters basically insane? It certainly fails
ne 4. 11. 2018 v 17:14 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > ne 4. 11. 2018 v 16:54 odesilatel Tom Lane napsal:
> >> In short, I think it's a bug that we allow the above. If you
> >> want to keep the must-be-a-variable error then it sh
po 5. 11. 2018 v 7:20 odesílatel Amit Langote
napsal:
> On 2018/11/04 4:58, Pavel Stehule wrote:
> > here is a patch
>
> Thank you, Pavel.
>
> Here are some comments.
>
> I mentioned it during the last review, but maybe you missed it due to the
> other discussion
po 5. 11. 2018 v 10:22 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 04/11/2018 16:54, Tom Lane wrote:
> > I looked into SQL:2011 to see what it has to say about this. In
> > 10.4 , syntax rule 9) g) iii) says
> >
> > For each SQL parameter Pi, 1 (one) ≤ i ≤ SRN
po 29. 10. 2018 v 11:45 odesílatel Pavel Stehule
napsal:
>
>
> po 29. 10. 2018 v 10:11 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> čt 25. 10. 2018 v 21:47 odesílatel Alvaro Herrera <
>> alvhe...@2ndquadrant.com> napsal:
>>
>>> On
út 6. 11. 2018 v 18:18 odesílatel Alvaro Herrera
napsal:
> On 2018-Nov-06, Surafel Temesgen wrote:
>
> > hi,
> >
> > On Sun, Nov 4, 2018 at 1:18 PM Fabien COELHO
> wrote:
> >
> > > Patch does not seem to apply anymore, could you rebase?
> > >
> > The attached patch is a rebased version and work
Hi
pá 26. 10. 2018 v 15:55 odesílatel Fabien COELHO
napsal:
>
> Hello,
>
> This is a follow-up to another patch I posted about libpq confusing
> documentation & psql resulting behavior under host/hostaddr settings.
>
> Although the first mostly documentation patch did not gather much
> enthousia
st 7. 11. 2018 v 16:25 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, 12 Oct 2018 at 07:52, Pavel Stehule
> wrote:
> >
> >> > postgres=# insert into test(v) values( '[]');
> >> > INSERT 0 1
> >> > postgr
st 7. 11. 2018 v 15:11 odesílatel Arthur Zakirov
napsal:
> Hello all,
>
> On 07.11.2018 16:23, Pavel Stehule wrote:
> > pá 26. 10. 2018 v 15:55 odesílatel Fabien COELHO > <mailto:coe...@cri.ensmp.fr>> napsal:
> > >
> > > This is a follow-up to
st 7. 11. 2018 v 19:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Wed, 7 Nov 2018 at 17:09, Pavel Stehule
> wrote:
> >
> > I don't agree. If we use a same syntax for some objects types, we
> should to enforce some consistency.
>
> J
Hi
We can pass variadic arguments as a array to any variadic function. But
some our old variadic functions doesn't supports this feature.
We cannot to write
SELECT least(VARIADIC ARRAY[1,2,3]);
Attached patch add this possibility to least, greatest functions.
Regards
Pavel
diff --git a/src/ba
Ahoj
dnes byly zverejneny opravne verze viz
https://www.postgresql.org/about/news/1905/
Pokud si hrajete s PostgreSQL 11, pripadne ji pouzivate produkcne, tak
neodkladejte upgrade.
Pavel
čt 8. 11. 2018 v 18:40 odesílatel Robert Haas
napsal:
> On Thu, Nov 8, 2018 at 12:31 PM Pavel Stehule
> wrote:
> > Ahoj
> >
> > dnes byly zverejneny opravne verze viz
> https://www.postgresql.org/about/news/1905/
> >
> > Pokud si hrajete s PostgreSQL 1
čt 8. 11. 2018 v 15:18 odesílatel Markus Winand
napsal:
>
> > On 2018-11-6, at 15:23 , Pavel Stehule wrote:
> >
> >
> >
> > po 29. 10. 2018 v 11:45 odesílatel Pavel Stehule <
> pavel.steh...@gmail.com> napsal:
> >
> >
> > po
pá 9. 11. 2018 v 6:57 odesílatel Michael Paquier
napsal:
> On Thu, Nov 08, 2018 at 01:58:34PM +0900, Michael Paquier wrote:
> > Anyway, I am still going through the patch, so no need to send a new
> > version for now.
>
> Okay, I have done a round of more in-depth review, and the patch looks
> to
Hi
There are some broken. I tried to fix plpgsql_check regression tests and I
found new error.
Looks it is fresh regression.
CREATE OR REPLACE PROCEDURE public.proc(a integer, INOUT b integer, c
integer)
LANGUAGE plpgsql
AS $procedure$
begin
b := a + c + c;
end;
$procedure$
CREATE OR REPLACE
pá 9. 11. 2018 v 20:05 odesílatel Pavel Stehule
napsal:
> Hi
>
> There are some broken. I tried to fix plpgsql_check regression tests and I
> found new error.
>
> Looks it is fresh regression.
>
> CREATE OR REPLACE PROCEDURE public.proc(a integer, INOUT b integer,
pá 9. 11. 2018 v 20:07 odesílatel Pavel Stehule
napsal:
>
>
> pá 9. 11. 2018 v 20:05 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> There are some broken. I tried to fix plpgsql_check regression tests and
>> I found new error.
>>
>> Lo
so 10. 11. 2018 v 19:12 odesílatel Vik Fearing
napsal:
> On 08/11/2018 15:59, Pavel Stehule wrote:
> > Hi
> >
> > We can pass variadic arguments as a array to any variadic function. But
> > some our old variadic functions doesn't supports this feature.
> >
po 12. 11. 2018 v 5:19 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Friday, November 9, 2018, Michael Paquier wrote:
>
>> On Fri, Nov 09, 2018 at 05:28:07PM +0100, Daniel Verite wrote:
>> > But again COPY is concerned with importing the data that preexists,
>> > even if
po 12. 11. 2018 v 6:58 odesílatel Markus Winand
napsal:
>
> On 2018-11-9, at 05:07 , Pavel Stehule wrote:
>
>
>
> čt 8. 11. 2018 v 15:18 odesílatel Markus Winand
> napsal:
>
>>
>> > On 2018-11-6, at 15:23 , Pavel Stehule wrote:
>> >
>>
út 13. 11. 2018 v 0:55 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > On 2018-11-13 00:01:49 +0100, David Fetter wrote:
> >> So if this got added to a lot of compilers, that might suffice.
>
> > No, unless those compiler versions will automatically be available in
> > older distros. Whi
Hi
We have good API and tools for monitoring slow queries. What is very good.
But I miss a monitoring fast queries what is usually major number and where
relatively small slowdown can to produce unhappy latencies on user
interface. More, the slowdowns here can shows some issues of database
health
út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Hello Pavel,
>
> What about using wait events and a trigger on pg_stat_activity ?
>
pg_stat_activity should not to show fresh data. Using pg_stat_activity can
be too expensive for fast queries
> just :
>
Hi
I am try to enhance plpgsql_check about profiler functionality and I have
to solve how to identify every plpgsql statement across different sessions.
There is lineno, but surely it should not be unique. I propose introduce
stmtid to every statement structure. This number will be unique inside
f
út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
tomas.von...@2ndquadrant.com> napsal:
> On Tue, 2018-11-13 at 13:55 +0100, Pavel Stehule wrote:
> > út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
> > legrand_legr...@hotmail.com> napsal:
> >
> > >
st 14. 11. 2018 v 14:06 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Pavel Stehule wrote
> > út 13. 11. 2018 v 20:38 odesílatel Tomas Vondra <
>
> > tomas.vondra@
>
> >> napsal:
> >
> > My idea is very simple.
> >
>
po 19. 11. 2018 v 3:42 odesílatel Michael Paquier
napsal:
> On Sun, Nov 18, 2018 at 11:17:37PM -0300, Alvaro Herrera wrote:
> > To be certain I'm not going against some old decision, I digged up
> > Amit's old patches. Turns out he submitted psql's describe.c using the
> > term "partitioned tabl
Hi
I am playing with plpgsql profiling and and plpgsql plugin API. I found so
callback stmt_beg and stmt_end was not called for top statement due direct
call exec_stmt_block function.
<-->estate.err_text = NULL;
<-->estate.err_stmt = (PLpgSQL_stmt *) (func->action);
<-->rc = exec_stmt_block(&esta
Hi
út 20. 11. 2018 v 11:09 odesílatel <066ce...@free.fr> napsal:
> Hi,
>
> I do have a reproductible crash with mysql_fdw when executing a plpgsql
> function. I'm running pg 11.1 with current mysql_fdw, but I had the same
> crash with the pg 9.6 and mysql_fdw provided with ubuntu packages.
>
> Fr
Hi
just rebase
Regards
Pavel
schema-variables-20181121-01.patch.gz
Description: application/gzip
út 20. 11. 2018 v 9:14 odesílatel Amit Langote <
langote_amit...@lab.ntt.co.jp> napsal:
> On 2018/11/20 16:50, Michael Paquier wrote:
> > Testing the feature, \dP shows all partitioned relations, still does not
> > show the relationship when multiple levels are used. Could it make
> > sense to al
út 20. 11. 2018 v 8:50 odesílatel Michael Paquier
napsal:
> On Mon, Nov 05, 2018 at 11:43:16AM +0100, Pavel Stehule wrote:
> > should be fixed now.
>
> Here are some notes on the last version.
>
> + " FROM pg_inherits i\n"
> Missi
st 21. 11. 2018 v 17:21 odesílatel Alvaro Herrera
napsal:
> Hmm, these tests are not going to work, because they have "pavel" in the
> expected output.
>
I was blind, thank you for check
fixed
Regards
Pavel
>
> --
> Álvaro Herrerahttps://www.2ndQuadrant.com/
> PostgreSQL Dev
čt 22. 11. 2018 v 1:51 odesílatel Michael Paquier
napsal:
> On Wed, Nov 21, 2018 at 05:37:33PM +0100, Pavel Stehule wrote:
> > st 21. 11. 2018 v 17:21 odesílatel Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > napsal:
> >> Hmm, these tests are not going to work,
čt 22. 11. 2018 v 15:29 odesílatel Michael Paquier
napsal:
> On Thu, Nov 22, 2018 at 12:42:14PM +0100, Pavel Stehule wrote:
> > Here my position is strong. \dP for me doesn't mean "tables or
> > indexes" - it means "partition tables with total relation size&
so 24. 11. 2018 v 22:03 odesílatel Corey Huinker
napsal:
>
>
>> >>psql> \if :i >= 5
>> >>
>> > I think we're ok with that so long as none of the operators or values
>> has a
>> > \ in it.
>> > What barriers do you see to re-using the pgbench grammar?
>>
>> The pgbench expression grammar mimic
po 26. 11. 2018 v 5:36 odesílatel Andrew Gierth
napsal:
> > "Tom" == Tom Lane writes:
>
> Tom> Or we could kill both issues by hard-wiring the separator as ','.
>
> Using ';' for the delimiter isn't all that rare.
>
; is default for CSV produced by MS Excel in Czech mutation - so for some
>
> Pushed with that correction and some other last-minute review.
>
Great! Thank you
Pavel
>
> regards, tom lane
>
>
st 28. 11. 2018 v 9:59 odesílatel Lætitia Avrot
napsal:
> Hi all,
>
> # What I'd like to do
> I've been working on the idea of a markdown format for psql as I had said
> in that thread :
> https://www.postgresql.org/message-id/flat/CAB_COdiiwTmBcrmjXWCKiqkcPgf_bLodrUyb4GYE6pfKeoK2eg%40mail.gmail.
Hi
čt 29. 11. 2018 v 14:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Sep 21, 2018 at 1:30 PM Pavel Stehule
> wrote:
> >
> > Thank you for comments
> >
> > Attached updated patch
>
> Unfortunately, current version of the pa
pá 30. 11. 2018 v 9:26 odesílatel Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> napsal:
> Hello.
>
> At Fri, 30 Nov 2018 07:48:26 +0100, Pavel Stehule
> wrote in <
> cafj8prd7zg07t4npzu09t4rgxz0btvyyg2emvoh+o_drnoi...@mail.gmail.com>
> > Hi
> >
čt 29. 11. 2018 v 7:58 odesílatel Michael Paquier
napsal:
> On Thu, Nov 22, 2018 at 03:47:11PM +0100, Pavel Stehule wrote:
> > I have not feel well when I see in one report numbers 40 and 16, I see
> much
> > more comfortable when I see 24 and 16, but for this I need a differe
Hi
I did update of plpgsql_check and I see, so some functions returns
different result than on older posgresql. Probably this is wanted behave,
but It should be mentioned as partial compatibility break, because some
regress test can be broken too.
create table t(i int);
create function test_t(OUT
2018-02-18 17:48 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > I did update of plpgsql_check and I see, so some functions returns
> > different result than on older posgresql. Probably this is wanted behave,
> > but It should be mentioned as partial compatibilit
2018-02-22 18:20 GMT+01:00 Thom Brown :
> Hi,
>
> I have found that Japanese language support for the database server
> has been dropped for 10. This is because it fell below the 80% of
> strings translated requirement, so it was shipped without Japanese.
> This isn't true of all components, but
801 - 900 of 2496 matches
Mail list logo
