On Sat, Apr 20, 2024 at 11:54:29AM +0900, Michael Paquier wrote:
> Will clean up.
While looking at the whole, I've noticed that this has been mentioned
here by Andres, but the committed patch did not get the call:
https://www.postgresql.org/message-id/20231117204441.7ff37sw53udg3...@awork3.anaraze
On Sat, Apr 20, 2024 at 5:03 PM Michael Paquier wrote:
>
> On Sat, Apr 20, 2024 at 11:54:29AM +0900, Michael Paquier wrote:
> > Will clean up.
>
> While looking at the whole, I've noticed that this has been mentioned
> here by Andres, but the committed patch did not get the call:
> https://www.pos
Hello hackers,
When playing with JSON_TABLE, I tried to replace tenk1 in regression tests
with a view based on JSON_TABLE, with the same content, and discovered
that for one sub-optimal query it's execution duration increased many-fold.
With the preparation script attached, I see the following du
Hi, thank you for your work with this subject.
While I was reviewing your code, I noticed that your patch conflicts
with another patch [0] that been committed.
[0]
https://www.postgresql.org/message-id/flat/CA%2BhUKGJkOiOCa%2Bmag4BF%2BzHo7qo%3Do9CFheB8%3Dg6uT5TUm2gkvA%40mail.gmail.com
On 28
On 20.04.2024 09:36, Daniel Gustafsson wrote:
Anton: please register this patch in the Open commitfest to ensure it's not
forgotten about.
Done.
Daniel and Michael thank you!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Lakhin writes:
> When playing with JSON_TABLE, I tried to replace tenk1 in regression tests
> with a view based on JSON_TABLE, with the same content, and discovered
> that for one sub-optimal query it's execution duration increased many-fold.
> With the preparation script attached, I see
I wrote:
> Alexander Lakhin writes:
>> explain (verbose, analyze)
>> select
>> (select max((select i.unique2 from tenk1 i where i.unique1 = o.unique1)))
>> from tenk1 o;
>> -- original tenk1
>> Execution Time: 4769.481 ms
> Hm, I get about 13 ms for that example. Do you have some really
> exp
On 19.04.24 13:04, Sriram RK wrote:
For any complier/hardware related issue we should able to provide support.
We are in the process of identifying the AIX systems that can be added
to the CI/buildfarm environment.
I think we should manage expectations here, if there is any hope of
getting A
Peter Eisentraut writes:
> I have some sympathy for this. The discussion about removing AIX
> support had a very short turnaround and happened in an unrelated thread,
> without any sort of public announcement or consultation. So this report
> of "hey, we were still using that" is timely and f
Alexander Lakhin writes:
> explain (verbose, analyze)
> select
>(select max((select i.unique2 from jsontable_tenk1 i where i.unique1 =
> o.unique1)))
> from jsontable_tenk1 o;
> -- Table Function Call: JSON_TABLE...
> Execution Time: 288310.131 ms
> (with 63% of time spent inside ExecEvalJs
On 2024-Apr-19, Tender Wang wrote:
> The new patch looks good to me.
Thanks for looking once more. I have pushed it now. I didn't try
pg_upgrade other than running the tests, so maybe buildfarm member crake
will have more to complain about -- we'll see.
--
Álvaro Herrera 48°01'N
On 2024-Apr-18, Andrew Dunstan wrote:
> On 2024-04-18 Th 11:39, Alvaro Herrera wrote:
> It's not that hard to make it go back to 9.2. Here's a version that's a
> couple of years old, but it supports versions all the way back to 7.2 :-)
Hmm, so I tried grabbing the old-version module definitions
Hi,
While doing some testing with createdb, I noticed it only accepts
file_copy/wal_log as valid strategies, not FILE_COPY/WAL_LOG (which is
what the docs say). The same thing applies to CREATE DATABASE.
The problem is that createdb() does the check using strcmp() which is
case-sensitive. IMHO th
Tomas Vondra writes:
> While doing some testing with createdb, I noticed it only accepts
> file_copy/wal_log as valid strategies, not FILE_COPY/WAL_LOG (which is
> what the docs say). The same thing applies to CREATE DATABASE.
Hmm, actually it does work in CREATE DATABASE:
regression=# create da
On 4/20/24 22:40, Tom Lane wrote:
> Tomas Vondra writes:
>> While doing some testing with createdb, I noticed it only accepts
>> file_copy/wal_log as valid strategies, not FILE_COPY/WAL_LOG (which is
>> what the docs say). The same thing applies to CREATE DATABASE.
>
> Hmm, actually it does wo
Tomas Vondra writes:
> On 4/20/24 22:40, Tom Lane wrote:
>> Seems reasonable. The alternative could be to remove createdb.c's use
>> of fmtId() here, but I don't think that's actually better.
> Why? It seems to me this is quite close to e.g. LOCALE_PROVIDER, and we
> don't do fmtId() for that. S
On Fri, Apr 19, 2024 at 01:59:31PM +0200, Alvaro Herrera wrote:
> BTW because of a concern from Justin that the NO INHERIT stuff will
> cause errors in old server versions, I started to wonder if it wouldn't
> be better to add these constraints in a separate line for compatibility,
> so for example
17 matches
Mail list logo
