Re: Resolve UNKNOWN type to relevant type instead of text type while bulk update using values

2023-01-04 Thread David G. Johnston
On Wednesday, January 4, 2023, Sayyid Ali Sajjad Rizavi wrote: > > > *Option 1:* Cast to the relevant column type in that position (to > `integer` in this case), whenever we have an unknown type. > This happens when possible so any remaining cases are not possible. Or, at least apparently not wo

Re: Fix showing XID of a spectoken lock in an incorrect field of pg_locks view.

2023-01-04 Thread Masahiko Sawada
On Wed, Jan 4, 2023 at 6:42 PM Amit Kapila wrote: > > On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada wrote: > > > > It seems to be confusing and the user won't get the result even if > > they search it by transactionid = 741. So I've attached the patch to > > fix it. With the patch, the pg_locks

Re: Resolve UNKNOWN type to relevant type instead of text type while bulk update using values

2023-01-04 Thread Sayyid Ali Sajjad Rizavi
> > Breaking working queries for this is not acceptable. Good point, let's exclude Option 2. > This happens when possible so any remaining cases are not possible. Or, > at least apparently not worth the effort it would take to make work. Actually this doesn't happen when all of the values in

Re: pgsql: Delay commit status checks until freezing executes.

2023-01-04 Thread Amit Kapila
On Wed, Jan 4, 2023 at 11:30 PM Peter Geoghegan wrote: > > On Wed, Jan 4, 2023 at 7:03 AM Robert Haas wrote: > > But that having been said, I'm kind of astonished that you didn't know > > about this already. The freezing behavior is in general extremely hard > > to get right, and I guess I feel i

Re: An oversight in ExecInitAgg for grouping sets

2023-01-04 Thread Richard Guo
On Thu, Jan 5, 2023 at 6:18 AM David Rowley wrote: > On Tue, 3 Jan 2023 at 10:25, Tom Lane wrote: > > The thing that I find really distressing here is that it's been > > like this for years and none of our automated testing caught it. > > You'd have expected valgrind testing to do so ... but it

Re: Resolve UNKNOWN type to relevant type instead of text type while bulk update using values

2023-01-04 Thread David G. Johnston
Please don’t top-post On Wednesday, January 4, 2023, Sayyid Ali Sajjad Rizavi wrote: > Breaking working queries for this is not acceptable. > > > Good point, let's exclude Option 2. > > >> This happens when possible so any remaining cases are not possible. Or, >> at least apparently not worth t

Re: Todo: Teach planner to evaluate multiple windows in the optimal order

2023-01-04 Thread David Rowley
On Thu, 5 Jan 2023 at 16:12, Tom Lane wrote: > > David Rowley writes: > > Additionally, it's also not that clear to me that sorting by more > > columns in the sort below the WindowAgg would always be a win over > > doing the final sort for the ORDER BY. What if the WHERE clause (that > > could n

Re: Todo: Teach planner to evaluate multiple windows in the optimal order

2023-01-04 Thread Ankit Kumar Pandey
On 05/01/23 12:53, David Rowley wrote: We *can* reuse Sorts where a more strict or equivalent sort order is available. The question is how do we get the final WindowClause to do something slightly more strict to save having to do anything for the ORDER BY. One way you might think would be to

Re: grouping pushdown

2023-01-04 Thread Antonin Houska
David Rowley wrote: > On Wed, 4 Jan 2023 at 23:21, Spring Zhong wrote: > > The plan is apparently inefficient, since the hash aggregate goes after the > > Cartesian product. We could expect the query's performance get much > > improved if the HashAggregate node can be pushed down to the SCAN n

<    1   2