On Sat, Jan 16, 2021 at 10:36 AM Bharath Rupireddy
wrote:
> > > Please consider the v9 patch set for further review.
> >
> > Thanks for updating the patch! I reviewed only 0001 patch.
I addressed the review comments and attached v10 patch set. Please
consider it for further review.
With
Hello Tom,
04.01.2021 08:47, Tom Lane wrote:
> Hm. There isn't anything about test_regex()'s API that I would want
> to expose to end users ;-) ... it's just designed to replicate the
> test API that Henry Spencer designed a couple decades ago, which IMO
> was not too clean even by the standards
Hi,
On 2021-01-17 11:54:57 +0530, Amit Kapila wrote:
> On Sun, Jan 17, 2021 at 5:38 AM Tom Kincaid wrote:
> > Admittedly I am a novice on this topic, and the majority of the
> > PostgreSQL source code, however I am hopeful enough (those of you who
> > know me understand that I suffer from
On Sun, Jan 17, 2021 at 5:38 AM Tom Kincaid wrote:
>
> > > > I think that's not at all acceptable. I don't mind hashing out details
> > > > on calls / off-list, but the design needs to be public, documented, and
> > > > reviewable. And if it's something the community can't understand, then
> > >
On Thu, Jan 14, 2021 at 6:49 PM Yugo NAGATA wrote:
>
> On Wed, 13 Jan 2021 17:49:43 +0530
> Dilip Kumar wrote:
>
> > On Wed, Jan 13, 2021 at 3:35 PM Dilip Kumar wrote:
> > >
> > > On Wed, Jan 13, 2021 at 3:27 PM Yugo NAGATA wrote:
> > > >
> > > > On Thu, 10 Dec 2020 11:25:23 +0530
> > > >
On Wed, Jan 13, 2021 at 11:16 PM Peter Geoghegan wrote:
>
> On Mon, Jan 11, 2021 at 9:26 PM Peter Geoghegan wrote:
> > I'm going to proceed with committing the original version of the patch
> > -- I feel that this settles it.
>
> Pushed both patches from the patch series just now.
>
Nice work!
On Sun, Jan 17, 2021 at 3:52 AM Masahiko Sawada wrote:
>
> On Sat, Jan 16, 2021 at 12:28 PM Masahiko Sawada
> wrote:
> >
> > ---
> > + /* test for recovery pause if user has requested the pause */
> > + if (((volatile XLogCtlData *) XLogCtl)->recoveryPause)
> > +
On Sun, Jan 17, 2021 at 01:23:39AM +0100, Tomas Vondra wrote:
> diff --git a/doc/src/sgml/ref/create_statistics.sgml
> b/doc/src/sgml/ref/create_statistics.sgml
> index 4363be50c3..5b8eb8d248 100644
> --- a/doc/src/sgml/ref/create_statistics.sgml
> +++ b/doc/src/sgml/ref/create_statistics.sgml
>
From: iwata@fujitsu.com
> This patch includes these items:
Is there anything else in this revision that is not handled?
Below are my comments.
Also, why don't you try running the regression tests with a temporary
modification to PQtrace() to output the trace to a file? The sole purpose
From: Osumi, Takamichi/大墨 昂道
> I updated my patch to take in those feedbacks !
> Have a look at the latest patch.
Looks good to me (the status remains ready for committer.)
Regards
Takayuki Tsunakawa
Hi,
+* Check that only the base rel is mentioned. (This should be dead code
+* now that add_missing_from is history.)
+*/
+ if (list_length(pstate->p_rtable) != 1)
If it is dead code, it can be removed, right ?
For statext_mcv_clauselist_selectivity:
+ //
I've been looking into the planner failure reported at [1].
The given test case is comparable to this query in the
regression database:
regression=# select i8.*, ss.v, t.unique2
from int8_tbl i8
left join int4_tbl i4 on i4.f1 = 1
left join lateral (select i4.f1 + 1 as v) as ss on true
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
access pg_statistics_ext_data.
Is this the expected behavior?
Hmmm, that's a good point. Bummer we haven't
For the record, this got committed as 6bc27698324 in December, along
with the other incremental sort fixes and improvements. I forgot to mark
it as committed in the app, so I've done that now.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
access pg_statistics_ext_data.
Is this the expected behavior?
--- operation ---
postgres=> CREATE STATISTICS stat1_data1 ON c1, c2 FROM data1;
CREATE STATISTICS
postgres=>
On Sat, Jan 16, 2021 at 12:03:19PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> >> So a non-rewriting conversion would only be possible if local time is
> >> identical to UTC; which is true for few enough people that nobody has
> >>
> > > I think that's not at all acceptable. I don't mind hashing out details
> > > on calls / off-list, but the design needs to be public, documented, and
> > > reviewable. And if it's something the community can't understand, then
> > > it can't get in. We're going to have to maintain this going
On 1/15/21 5:19 PM, Tomas Vondra wrote:
On 1/15/21 9:47 AM, Julien Rouhaud wrote:
On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/13 7:48, Tatsuro Yamada wrote:
On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
On
On Sat, Jan 16, 2021 at 05:48:43PM +0100, Tomas Vondra wrote:
> +
> + expr text
> +
> +
> + Expression the extended statistics is defined on
> +
Expression the extended statistics ARE defined on
Or maybe say "on which the extended statistics are defined"
> +
> If we agree on removing heap_multi_insert_v2 API and embed that logic
> inside heap_insert_v2, then we can do this - pass the required
> information and the functions ExecInsertIndexTuples and
> ExecARInsertTriggers as callbacks so that, whether or not
> heap_insert_v2 choses single or multi
On Sat, Jan 16, 2021 at 12:28 PM Masahiko Sawada wrote:
>
> ---
> + /* test for recovery pause if user has requested the pause */
> + if (((volatile XLogCtlData *) XLogCtl)->recoveryPause)
> + recoveryPausesHere(false);
> +
> + now = GetCurrentTimestamp();
> +
>
> Hmm,
On 1/16/21 4:11 PM, Anastasia Lubennikova wrote:
> ...
As Pavan correctly figured it out before the problem is that
RelationGetBufferForTuple() moves to the next page, losing free space in
the block:
> ... I see that a relcache invalidation arrives
> after 1st and then after every
On Fri, 2021-01-15 at 13:55 -0800, Andres Freund wrote:
> Has anybody dug out the thread leading to the commit?
https://www.postgresql.org/message-id/CAMsr%2BYEN04ztb%2BSDb_UfD72Kg5M3F%2BCpad31QBKT2rRjysmxRg%40mail.gmail.com
Regards,
Jeff Davis
vignesh C writes:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
>> Why is a full signal needed? Seems the procsignal infrastructure should
>> suffice?
> Most of the processes have access to ProcSignal, for these processes
> printing of callstack signal was handled by using ProcSignal.
Vik Fearing writes:
> With respect, you are looking at a 10-year-old document and I am not.
> 5.3 has since been modified.
Is a newer version of the spec available online?
regards, tom lane
On Sat, Jan 16, 2021, at 17:21, Vik Fearing wrote:
> I agree on the conciseness, but I'm wondering what performance problem
> you think there is with the CROSS JOIN LATERAL VALUES technique. Have
> you tried running an EXPLAIN (ANALYZE, VERBOSE) on that?
Yes, I've tried, it results in the same
On 1/16/21 7:39 PM, Surafel Temesgen wrote:
> On Fri, Jan 15, 2021 at 8:02 PM Simon Riggs
> wrote:
>
>>
>> There are no existing applications, so for PostgreSQL, it wouldn't be an
>> issue.
>>
>>
> Yes we don't have but the main function of ALTER TABLE foo ADD SYSTEM
> VERSIONING
> is to add
On Fri, Jan 15, 2021 at 8:02 PM Simon Riggs
wrote:
>
> There are no existing applications, so for PostgreSQL, it wouldn't be an
> issue.
>
>
Yes we don't have but the main function of ALTER TABLE foo ADD SYSTEM
VERSIONING
is to add system versioning functionality to existing application
regards
Hi,
On Sat, Jan 16, 2021, at 09:34, vignesh C wrote:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
> >
> > On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> > > On 2020-12-08 10:38, vignesh C wrote:
> > > > I have implemented printing of backtrace based on handling it in
> > > >
On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
>
> On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> > On 2020-12-08 10:38, vignesh C wrote:
> > > I have implemented printing of backtrace based on handling it in
> > > CHECK_FOR_INTERRUPTS. This patch also includes the change to allow
On 1/16/21 6:10 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 1/16/21 4:32 PM, Andreas Karlsson wrote:
>>> On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
Vik Fearing writes:
> On 1/16/21 4:32 PM, Andreas Karlsson wrote:
>> On 1/16/21 2:02 PM, Vik Fearing wrote:
>>> I am in favor of such a change so that we can also accept 1_000_000
>>> which currently parses as "1 AS _000_000" (which also isn't compliant
>>> because identifiers cannot start with
Noah Misch writes:
> On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
>> So a non-rewriting conversion would only be possible if local time is
>> identical to UTC; which is true for few enough people that nobody has
>> bothered with attempting the optimization.
> PostgreSQL 12 and later
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
> On 1/16/21 2:02 PM, Vik Fearing wrote:
>> I am in favor of such a change so that we can also accept 1_000_000
>> which currently parses as "1 AS _000_000" (which also isn't compliant
>> because identifiers cannot start with an underscore, but I don't
Hi hackers!
Does anyone maintain opensource pg_surgery analogs for released versions of PG?
It seems to me I'll have to use something like this and I just though that I
should consider pg_surgery in favour of our pg_dirty_hands.
Thanks!
Best regards, Andrey Borodin.
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to
On 12.01.2021 22:30, Tomas Vondra wrote:
Thanks. These patches seem to resolve the TOAST table issue, freezing
it as expected. I think the code duplication is not an issue, but I
wonder why heap_insert uses this condition:
/*
* ...
*
* No need to update the visibilitymap if
On 1/14/21 6:42 PM, Surafel Temesgen wrote:
> Hi Simon,
> Thank you for all the work you does
>
> On Mon, Jan 11, 2021 at 5:02 PM Simon Riggs
> wrote:
>
>>
>>
>> * Anomalies around use of CURRENT_TIMESTAMP are not discussed or resolved.
>> Probably need to add a test that end_timestamp >
On 1/14/21 10:22 PM, Simon Riggs wrote:
> On Thu, Jan 14, 2021 at 5:46 PM Surafel Temesgen
> wrote:
>
>> On Fri, Jan 8, 2021 at 7:50 PM Ryan Lambert wrote:
>>>
>>> I prefer to have them hidden by default. This was mentioned up-thread with
>>> no decision, it seems the standard is ambiguous.
On 1/3/21 1:12 PM, Joel Jacobson wrote:
> Hi hackers,
>
> I just learned about a feature called "LET clause".
>
> It's not part of the SQL standard, but it's supported by Oracle [1],
> Couchbase [2] and AsterixDB [3].
>
> I searched the pgsql-hackers archives and couldn't find any matches on
On 12/30/20 12:59 PM, Noah Misch wrote:
> On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
>> https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave $SUBJECT
>> as
>> one of the constituent projects for changing the public schema default ACL.
>> This ended up being simple.
On 12/29/20 10:18 AM, Peter Eisentraut wrote:
> On 2020-12-28 21:54, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> I was surprised to find that this doesn't error:
>>> => select 100a;
>>> a
>>> -
>>> 100
>>
>>> I suspect this and similar cases used to error before aliases without AS
On Sat, Jan 16, 2021 at 12:21 PM Bharath Rupireddy
wrote:
> > In the test, can we have multiple publications for the subscription
> > because that is how we discovered that the originally proposed patch
> > was not correct? Also, is it possible to extend some of the existing
> > tests in
On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> So a non-rewriting conversion would only be possible if local time is
> identical to UTC; which is true for few enough people that nobody has
> bothered with attempting the optimization.
PostgreSQL 12 and later do have that optimization.
44 matches
Mail list logo
