Re: \watch 0 or \watch 0.00001 doesn't do what I want

2024-10-12 Thread Michael Paquier
On Thu, Oct 10, 2024 at 10:47:25AM +0500, Andrey M. Borodin wrote: > Let’s add a comment to tight-loop if statement. And a test for the case. + /* Tight loop, no wait needed */ + if (sleep_ms == 0) Okay about this addition. +psql_like($node, sprintf('SELECT 1 \watch c=3 i=%g', 0.0001

Re: Allow default \watch interval in psql to be configured

2024-10-12 Thread Michael Paquier
On Thu, Oct 10, 2024 at 09:43:27AM +0200, Daniel Gustafsson wrote: > I'm not sure I follow, it's true that the unit is seconds but the patch > doesn't > change the ability to use fractions of a second that we already support today. > > db=# \echo :WATCH_INTERVAL > 2 > db=# \set WATCH_INTERVAL 0.1

Re: Inval reliability, especially for inplace updates

2024-10-12 Thread Noah Misch
On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote: > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple > are unlocked outside the critical section. Why do we have to move the > buffer unlock within the critical section here? My guess is that it > needs to be unlocked

Re: POC, WIP: OR-clause support for indexes

2024-10-12 Thread Alexander Korotkov
On Fri, Oct 11, 2024 at 7:15 PM Alexander Korotkov wrote: > > On Fri, Oct 11, 2024 at 4:20 PM Alexander Korotkov > wrote: >> >> This is all for now. The feedback is welcome. > > Just figured out, I forgot the patchset itself. Here it goes. I forgot to specify (COSTS OFF) for EXPLAINs in regre

RE: Statistics Import and Export

2024-10-12 Thread Shinoda, Noriyoshi (SXD Japan FSIP)
Hi, Thank you for developing this great feature. I have tested the committed feature. The manual for the pg_set_relation_stats function says the following: "The value of relpages must be greater than or equal to 0" However, this function seems to accept -1 for the relpages parameter. Below is

Re: Inval reliability, especially for inplace updates

2024-10-12 Thread Nitin Motiani
On Sat, Oct 12, 2024 at 5:47 PM Noah Misch wrote: > > Rebased. Hi, I have a couple of questions : 1. In heap_inplace_update_and_unlock, currently both buffer and tuple are unlocked outside the critical section. Why do we have to move the buffer unlock within the critical section here? My guess

Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan

2024-10-12 Thread Alexander Lakhin
Hello Richard and Tom, 04.09.2024 06:50, Richard Guo wrote: I pushed this patch with the test case remaining, as it adds only a minimal number of test cycles. I explained in the commit message why the test case is included in equivclass.sql rather than in join.sql. While playing with the equi

Re: Proposal to Enable/Disable Index using ALTER INDEX

2024-10-12 Thread Shayon Mukherjee
> On Oct 9, 2024, at 1:41 PM, Robert Haas wrote: > > On Wed, Oct 9, 2024 at 4:19 AM David Rowley > wrote: >> On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee wrote: >>> [thinking…] Unless - we try to do support both a GUC and the ALTER INDEX >>> ENABLE/DISABLE gramma

Re: Proposal to Enable/Disable Index using ALTER INDEX

2024-10-12 Thread Shayon Mukherjee
Hi David, Answered below > On Oct 9, 2024, at 9:19 AM, David Rowley wrote: > > On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee wrote: >> [thinking…] Unless - we try to do support both a GUC and the ALTER INDEX >> ENABLE/DISABLE grammar + isdisabled attribute on pg_index? > > I just wanted to

Re: Proposal to Enable/Disable Index using ALTER INDEX

2024-10-12 Thread Vinícius Abrahão
On Wed, Oct 9, 2024 at 1:41 PM Robert Haas wrote: > On Wed, Oct 9, 2024 at 4:19 AM David Rowley wrote: > > On Wed, 9 Oct 2024 at 20:07, Shayon Mukherjee wrote: > > > [thinking…] Unless - we try to do support both a GUC and the ALTER > INDEX ENABLE/DISABLE grammar + isdisabled attribute on pg_in

Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

2024-10-12 Thread jian he
On Wed, Oct 9, 2024 at 4:18 AM Tom Lane wrote: > > In the attached v4 in the upper code two branch, both will call CleanQuerytext so in script_error_callback + /* + * If we have a location (which, as said above, we really always should) + * then report a line number to aid in localizing proble