Thanks for clarifying, Tomas.
Yes - it appears Google Cloud SQL automatically updates minor versions of
Postgres but hasn't updated beyond 13.1 yet.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 3/1/21 8:23 PM, rbrooks wrote:
Just a bump to see if there is a time frame for a fix on this.
Google Cloud doesn't yet support setting the *enable_incremental_sort * flag
yet.
Was able to temporarily resolve by running the following though:
ALTER DATABASE corpdb SET enable_incremental_sort T
Just a bump to see if there is a time frame for a fix on this.
Google Cloud doesn't yet support setting the *enable_incremental_sort * flag
yet.
Was able to temporarily resolve by running the following though:
ALTER DATABASE corpdb SET enable_incremental_sort TO OFF;
Hope this helps others until
On 12/16/20 1:51 AM, Jaime Casanova wrote:
> On Tue, Dec 1, 2020 at 4:08 AM Anastasia Lubennikova
> wrote:
>>
>> On 01.12.2020 03:08, James Coleman wrote:
>>> On Tue, Nov 3, 2020 at 4:39 PM Tomas Vondra
>>> wrote:
I've pushed the 0001 part, i.e. the main fix. Not sure about the other
On Tue, Dec 1, 2020 at 4:08 AM Anastasia Lubennikova
wrote:
>
> On 01.12.2020 03:08, James Coleman wrote:
> > On Tue, Nov 3, 2020 at 4:39 PM Tomas Vondra
> > wrote:
> >> I've pushed the 0001 part, i.e. the main fix. Not sure about the other
> >> parts (comments and moving the code back to postgre
On 01.12.2020 03:08, James Coleman wrote:
On Tue, Nov 3, 2020 at 4:39 PM Tomas Vondra
wrote:
I've pushed the 0001 part, i.e. the main fix. Not sure about the other
parts (comments and moving the code back to postgres_fdw) yet.
I noticed the CF entry [1] got moved to the next CF; I'm thinking t
On Tue, Nov 3, 2020 at 4:39 PM Tomas Vondra
wrote:
> I've pushed the 0001 part, i.e. the main fix. Not sure about the other
> parts (comments and moving the code back to postgres_fdw) yet.
I noticed the CF entry [1] got moved to the next CF; I'm thinking this
entry should be marked as committed s
On Wed, Nov 25, 2020 at 2:53 PM James Coleman wrote:
>
> On Tue, Nov 24, 2020 at 2:31 PM Tom Lane wrote:
> >
> > James Coleman writes:
> > > On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote:
> > >> 1. James was wondering, far upthread, why we would do projections
> > >> pre-sort or post-sort. I
On Tue, Nov 24, 2020 at 2:31 PM Tom Lane wrote:
>
> James Coleman writes:
> > On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote:
> >> 1. James was wondering, far upthread, why we would do projections
> >> pre-sort or post-sort. I think the answers can be found by studying
> >> planner.c's make_sor
James Coleman writes:
> On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote:
>> 1. James was wondering, far upthread, why we would do projections
>> pre-sort or post-sort. I think the answers can be found by studying
>> planner.c's make_sort_input_target(), which separates out what we want
>> to do p
On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote:
>
> James Coleman writes:
> > But I think that still leaves something missing: after all,
> > prepare_sort_from_pathkeys does know how to insert new target list
> > entries, so something either there (or in the caller/how its called)
> > has to be e
James Coleman writes:
> But I think that still leaves something missing: after all,
> prepare_sort_from_pathkeys does know how to insert new target list
> entries, so something either there (or in the caller/how its called)
> has to be enforcing an apparently implicit rule about what point in
> th
Thanks much for the detailed followup; this is super helpful.
On Fri, Nov 20, 2020 at 2:57 PM Robert Haas wrote:
>
> On Fri, Nov 20, 2020 at 1:51 PM James Coleman wrote:
> > > This isn't a counterexample, because there's no join tree here -- or,
> > > well, there is, but it's trivial, because th
On Fri, Nov 20, 2020 at 1:51 PM James Coleman wrote:
> > This isn't a counterexample, because there's no join tree here -- or,
> > well, there is, but it's trivial, because there's only one relation
> > involved. You can't have a non-Var expression computed before you
> > finish all the joins, bec
On Fri, Nov 20, 2020 at 12:06 PM Robert Haas wrote:
>
> On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra
> wrote:
> > I'm still not entirely sure I understand what's happening, or what the
> > exact rule is. Consider this query:
> >
> >explain (verbose) select distinct i, t, md5(t) from ref_0;
> >
On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra
wrote:
> I'm still not entirely sure I understand what's happening, or what the
> exact rule is. Consider this query:
>
>explain (verbose) select distinct i, t, md5(t) from ref_0;
>
> which on PG12 (i.e. before incremental sort) is planned like this:
On Tue, Nov 17, 2020 at 11:20 AM Tomas Vondra
wrote:
>
>
>
> On 11/17/20 3:03 PM, James Coleman wrote:
> > On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra
> > wrote:
> >>
> >> Hmm, I missed that other thread. That indeed seems like a bug in the
> >> same area already tweaked by ebb7ae839d033d0f2 fo
On 11/17/20 3:03 PM, James Coleman wrote:
> On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra
> wrote:
>>
>> Hmm, I missed that other thread. That indeed seems like a bug in the
>> same area already tweaked by ebb7ae839d033d0f2 for similar cases.
>
> I meant to bring it up in this thread before we
On Mon, Nov 16, 2020 at 11:23 PM Tomas Vondra
wrote:
>
> Hmm, I missed that other thread. That indeed seems like a bug in the
> same area already tweaked by ebb7ae839d033d0f2 for similar cases.
I meant to bring it up in this thread before we got the other patch
committed, but I just ended up not
Hmm, I missed that other thread. That indeed seems like a bug in the
same area already tweaked by ebb7ae839d033d0f2 for similar cases.
The attached patch fixes this simply by adding is_parallel_safe to
get_useful_pathkeys_for_relation - that does fix the reproducer, but I'm
not entirely sure that'
I've pushed the 0001 part, i.e. the main fix. Not sure about the other
parts (comments and moving the code back to postgres_fdw) yet.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, Tomas!
I'm still havin
On Tue, Nov 03, 2020 at 03:37:43AM +0100, Tomas Vondra wrote:
On Fri, Oct 30, 2020 at 07:37:33PM -0400, James Coleman wrote:
...
I was looking at this some more, and I'm still convinced that this is
correct, but I don't think a comment about it being an optimization
(though I suspect that that
On Fri, Oct 30, 2020 at 07:37:33PM -0400, James Coleman wrote:
...
I was looking at this some more, and I'm still convinced that this is
correct, but I don't think a comment about it being an optimization
(though I suspect that that its major benefit), since it came from,
and must parallel, fin
On Fri, Oct 30, 2020 at 5:03 PM Tomas Vondra
wrote:
>
> On Fri, Oct 30, 2020 at 01:26:08PM -0400, James Coleman wrote:
> >On Thu, Oct 29, 2020 at 6:06 PM Tomas Vondra
> > wrote:
> >>
> >> On Tue, Oct 06, 2020 at 09:37:31AM -0400, James Coleman wrote:
> >> >On Tue, Oct 6, 2020 at 9:28 AM Jaime Casa
On Fri, Oct 30, 2020 at 01:26:08PM -0400, James Coleman wrote:
On Thu, Oct 29, 2020 at 6:06 PM Tomas Vondra
wrote:
On Tue, Oct 06, 2020 at 09:37:31AM -0400, James Coleman wrote:
>On Tue, Oct 6, 2020 at 9:28 AM Jaime Casanova
> wrote:
>> Can you please create an entry in the commitfest for this
On Thu, Oct 29, 2020 at 6:06 PM Tomas Vondra
wrote:
>
> On Tue, Oct 06, 2020 at 09:37:31AM -0400, James Coleman wrote:
> >On Tue, Oct 6, 2020 at 9:28 AM Jaime Casanova
> > wrote:
> >> Can you please create an entry in the commitfest for this one so we
> >> don't lose track of it?
> >
>
> We're not
On Tue, Oct 06, 2020 at 09:37:31AM -0400, James Coleman wrote:
On Tue, Oct 6, 2020 at 9:28 AM Jaime Casanova
wrote:
Can you please create an entry in the commitfest for this one so we
don't lose track of it?
We're not too far from the next minor release, so I've been looking at
this fix aga
On Wed, Oct 7, 2020 at 6:22 PM Tomas Vondra
wrote:
>
> On Wed, Oct 07, 2020 at 04:01:27PM -0400, James Coleman wrote:
> >On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
> >>
> >> On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> >> > The plan (obtained by replacing the volatile function wi
On Wed, Oct 07, 2020 at 03:52:04PM -0400, Robert Haas wrote:
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
The plan (obtained by replacing the volatile function with a stable one):
Unique
-> Nested Loop
-> Gather Merge
Workers Planned: 2
-> S
On Wed, Oct 07, 2020 at 04:01:27PM -0400, James Coleman wrote:
On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> The plan (obtained by replacing the volatile function with a stable one):
>
> Unique
>-> Nested Loop
> -> Gath
On Wed, Oct 7, 2020 at 3:52 PM Robert Haas wrote:
>
> On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> > The plan (obtained by replacing the volatile function with a stable one):
> >
> > Unique
> >-> Nested Loop
> > -> Gather Merge
> >Workers Planned: 2
> >
On Thu, Oct 1, 2020 at 9:03 AM James Coleman wrote:
> The plan (obtained by replacing the volatile function with a stable one):
>
> Unique
>-> Nested Loop
> -> Gather Merge
>Workers Planned: 2
>-> Sort
> Sort Key: ref_0.i, (md5(
On Tue, Oct 6, 2020 at 9:28 AM Jaime Casanova
wrote:
> Can you please create an entry in the commitfest for this one so we
> don't lose track of it?
Done.
On Tue, 6 Oct 2020 at 06:46, James Coleman wrote:
>
> > All right, here's a modified patch. I did a bit of surgery: the
> > concept is the same, but I decided to explicitly not the parallels to
> > (and follow as possible) prepare_sort_from_pathkeys(). That means we
> > only have to do the express
On Mon, Oct 5, 2020 at 10:38 PM James Coleman wrote:
>
> On Mon, Oct 5, 2020 at 11:33 AM James Coleman wrote:
> >
> > On Sun, Oct 4, 2020 at 9:40 PM James Coleman wrote:
> > >
> > > On Sat, Oct 3, 2020 at 10:10 PM James Coleman wrote:
> > > >
> > > > On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
On Mon, Oct 5, 2020 at 11:33 AM James Coleman wrote:
>
> On Sun, Oct 4, 2020 at 9:40 PM James Coleman wrote:
> >
> > On Sat, Oct 3, 2020 at 10:10 PM James Coleman wrote:
> > >
> > > On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
> > > wrote:
> > > >
> > > > On Sat, Oct 03, 2020 at 10:50:06AM -0400
On Sun, Oct 4, 2020 at 9:40 PM James Coleman wrote:
>
> On Sat, Oct 3, 2020 at 10:10 PM James Coleman wrote:
> >
> > On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
> > wrote:
> > >
> > > On Sat, Oct 03, 2020 at 10:50:06AM -0400, James Coleman wrote:
> > > >On Fri, Oct 2, 2020 at 11:16 PM James Cole
On Sat, Oct 3, 2020 at 10:10 PM James Coleman wrote:
>
> On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
> wrote:
> >
> > On Sat, Oct 03, 2020 at 10:50:06AM -0400, James Coleman wrote:
> > >On Fri, Oct 2, 2020 at 11:16 PM James Coleman wrote:
> > >>
> > >> On Fri, Oct 2, 2020 at 7:07 PM James Colema
On Sat, Oct 3, 2020 at 5:44 PM Tomas Vondra
wrote:
>
> On Sat, Oct 03, 2020 at 10:50:06AM -0400, James Coleman wrote:
> >On Fri, Oct 2, 2020 at 11:16 PM James Coleman wrote:
> >>
> >> On Fri, Oct 2, 2020 at 7:07 PM James Coleman wrote:
> >> >
> >> > On Fri, Oct 2, 2020 at 6:28 PM Tomas Vondra
>
On Sat, Oct 03, 2020 at 10:50:06AM -0400, James Coleman wrote:
On Fri, Oct 2, 2020 at 11:16 PM James Coleman wrote:
On Fri, Oct 2, 2020 at 7:07 PM James Coleman wrote:
>
> On Fri, Oct 2, 2020 at 6:28 PM Tomas Vondra
> wrote:
> >
> > On Fri, Oct 02, 2020 at 05:45:52PM -0400, James Coleman wro
On Sat, 3 Oct 2020 at 08:15, James Coleman wrote:
>
> Jaime: was the backtrace in the original report by any chance record
> from breakpointing in the first call to get_sortgroupref_tle() (and
> one that successfully returned a sort group ref) rather than a call
> that hit the elog error on line 3
On Fri, Oct 2, 2020 at 11:16 PM James Coleman wrote:
>
> On Fri, Oct 2, 2020 at 7:07 PM James Coleman wrote:
> >
> > On Fri, Oct 2, 2020 at 6:28 PM Tomas Vondra
> > wrote:
> > >
> > > On Fri, Oct 02, 2020 at 05:45:52PM -0400, James Coleman wrote:
> > > >On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondr
On Fri, Oct 2, 2020 at 2:25 PM Tomas Vondra
wrote:
>
> The backtrace looks like this:
>
> #0 get_sortgroupref_tle
> #1 0x00808ab9 in prepare_sort_from_pathkeys
> #2 0x0080926c in make_sort_from_pathkeys
> #3 0x00801032 in create_sort_plan
> #4
On Fri, Oct 2, 2020 at 7:07 PM James Coleman wrote:
>
> On Fri, Oct 2, 2020 at 6:28 PM Tomas Vondra
> wrote:
> >
> > On Fri, Oct 02, 2020 at 05:45:52PM -0400, James Coleman wrote:
> > >On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondra
> > > wrote:
> > >>
> > >> ...
> > >>
> > >> More importanly, it doe
On Fri, Oct 2, 2020 at 6:28 PM Tomas Vondra
wrote:
>
> On Fri, Oct 02, 2020 at 05:45:52PM -0400, James Coleman wrote:
> >On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondra
> > wrote:
> >>
> >> ...
> >>
> >> More importanly, it does not actually fix the issue - it does fix that
> >> particular query, but
On Fri, Oct 02, 2020 at 05:45:52PM -0400, James Coleman wrote:
On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondra
wrote:
...
More importanly, it does not actually fix the issue - it does fix that
particular query, but just replacing the DISTINCT with either ORDER BY
or GROUP BY make it fail again :-
On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondra
wrote:
> >And I don't see any reason why the CASE statement couldn't in theory
> >(I don't know the internals enough to know when it actually happens)
> >be done as part of the base relation scan (in this case, the seq
> >scan). It's not dependent on any
On Fri, Oct 2, 2020 at 4:56 PM Tomas Vondra
wrote:
>
> On Fri, Oct 02, 2020 at 04:12:11PM -0400, James Coleman wrote:
> >On Fri, Oct 2, 2020 at 2:25 PM Tomas Vondra
> > wrote:
> >>
> >> On Fri, Oct 02, 2020 at 10:55:14AM -0400, James Coleman wrote:
> >> >On Fri, Oct 2, 2020 at 10:53 AM James Colem
On Fri, Oct 02, 2020 at 04:12:11PM -0400, James Coleman wrote:
On Fri, Oct 2, 2020 at 2:25 PM Tomas Vondra
wrote:
On Fri, Oct 02, 2020 at 10:55:14AM -0400, James Coleman wrote:
>On Fri, Oct 2, 2020 at 10:53 AM James Coleman wrote:
>>
>> On Fri, Oct 2, 2020 at 10:32 AM Tomas Vondra
>> wrote:
On Fri, Oct 2, 2020 at 2:25 PM Tomas Vondra
wrote:
>
> On Fri, Oct 02, 2020 at 10:55:14AM -0400, James Coleman wrote:
> >On Fri, Oct 2, 2020 at 10:53 AM James Coleman wrote:
> >>
> >> On Fri, Oct 2, 2020 at 10:32 AM Tomas Vondra
> >> wrote:
> >> >
> >> > On Fri, Oct 02, 2020 at 09:19:44AM -0400,
On Fri, Oct 02, 2020 at 10:55:14AM -0400, James Coleman wrote:
On Fri, Oct 2, 2020 at 10:53 AM James Coleman wrote:
On Fri, Oct 2, 2020 at 10:32 AM Tomas Vondra
wrote:
>
> On Fri, Oct 02, 2020 at 09:19:44AM -0400, James Coleman wrote:
> >
> > ...
> >
> >I've been able to confirm that the prob
On Fri, Oct 2, 2020 at 10:53 AM James Coleman wrote:
>
> On Fri, Oct 2, 2020 at 10:32 AM Tomas Vondra
> wrote:
> >
> > On Fri, Oct 02, 2020 at 09:19:44AM -0400, James Coleman wrote:
> > >
> > > ...
> > >
> > >I've been able to confirm that the problem goes away if we stop adding
> > >the gather m
On Fri, Oct 2, 2020 at 10:32 AM Tomas Vondra
wrote:
>
> On Fri, Oct 02, 2020 at 09:19:44AM -0400, James Coleman wrote:
> >
> > ...
> >
> >I've been able to confirm that the problem goes away if we stop adding
> >the gather merge paths in generate_useful_gather_paths().
> >
> >I'm not sure yet what
On Fri, Oct 02, 2020 at 09:19:44AM -0400, James Coleman wrote:
...
I've been able to confirm that the problem goes away if we stop adding
the gather merge paths in generate_useful_gather_paths().
I'm not sure yet what conclusion that leads us to. It seems to be that
the biggest clue remains th
On Thu, Oct 1, 2020 at 9:10 PM James Coleman wrote:
>
> On Thu, Oct 1, 2020 at 6:08 PM Tomas Vondra
> wrote:
> >
> > On Thu, Oct 01, 2020 at 09:02:57AM -0400, James Coleman wrote:
> > >On Thu, Oct 1, 2020 at 3:09 AM Jaime Casanova
> > > wrote:
> > >>
> > >> On Wed, 30 Sep 2020 at 21:21, James Col
On Thu, Oct 1, 2020 at 6:08 PM Tomas Vondra
wrote:
>
> On Thu, Oct 01, 2020 at 09:02:57AM -0400, James Coleman wrote:
> >On Thu, Oct 1, 2020 at 3:09 AM Jaime Casanova
> > wrote:
> >>
> >> On Wed, 30 Sep 2020 at 21:21, James Coleman wrote:
> >> >
> >> > On Sat, Sep 26, 2020 at 2:49 PM Jaime Casano
On Thu, Oct 01, 2020 at 09:02:57AM -0400, James Coleman wrote:
On Thu, Oct 1, 2020 at 3:09 AM Jaime Casanova
wrote:
On Wed, 30 Sep 2020 at 21:21, James Coleman wrote:
>
> On Sat, Sep 26, 2020 at 2:49 PM Jaime Casanova
> wrote:
> >
> > Hi,
> >
> > With sqlsmith I found a query that gives this
On Thu, Oct 1, 2020 at 3:09 AM Jaime Casanova
wrote:
>
> On Wed, 30 Sep 2020 at 21:21, James Coleman wrote:
> >
> > On Sat, Sep 26, 2020 at 2:49 PM Jaime Casanova
> > wrote:
> > >
> > > Hi,
> > >
> > > With sqlsmith I found a query that gives this error:
> > > ERROR: ORDER/GROUP BY expression n
On Wed, 30 Sep 2020 at 21:21, James Coleman wrote:
>
> On Sat, Sep 26, 2020 at 2:49 PM Jaime Casanova
> wrote:
> >
> > Hi,
> >
> > With sqlsmith I found a query that gives this error:
> > ERROR: ORDER/GROUP BY expression not found in targetlist
> >
[...]
> >
> > But if I set enable_incremental_s
On Sat, Sep 26, 2020 at 2:49 PM Jaime Casanova
wrote:
>
> Hi,
>
> With sqlsmith I found a query that gives this error:
> ERROR: ORDER/GROUP BY expression not found in targetlist
>
> I noted the query (sql query below, sorry it uses custom tables i
> couldn't replicate with regression tables) beca
Hi,
With sqlsmith I found a query that gives this error:
ERROR: ORDER/GROUP BY expression not found in targetlist
I noted the query (sql query below, sorry it uses custom tables i
couldn't replicate with regression tables) because it doesn't include
an ORDER/GROUP BY clause.
--- 0
select d
61 matches
Mail list logo
