On 2025/3/14 02:10, Christoph Berg wrote:
Hi,
I'm picking up a 5 year old patch again:
https://www.postgresql.org/message-id/flat/20191108132419.GG8017%40msg.df7cb.de
Users will be interested in knowing how much extra data they can load
into a database, but PG currently does not expose that n
On 2025/3/4 23:57, Trey Boudreau wrote:
On Mar 3, 2025, at 10:39 PM, Quan Zongliang
wrote:
I implemented a LISTEN command that supports matching names in the
LIKE format.
Just like
LISTEN 'c%';
NOTIFY c1;NOTIFY c2;
Notifications are received for c1 and c2.
The parser
On 2025/3/6 00:42, Tom Lane wrote:
Aleksander Alekseev writes:
For instance, if I do:
```
LISTEN aaafoo;
LISTEN aaabar;
UNLISTEN aaa%;
```
Should I:
A. be unsubscribed from aaafoo and aaabar since both match aaa% or
B. UNLISTEN should have no effect since I never subscribed to aaa%
I implemented a LISTEN command that supports matching names in the LIKE
format.
Just like
LISTEN 'c%';
NOTIFY c1;NOTIFY c2;
Notifications are received for c1 and c2.
For grammatical reasons, LISTEN 'v_'; with LISTEN v_; It's weird.
Should it be defined in a way that makes it easier to distin
Hi
Now, the varlena type is stored directly in the array. Did not consider
short varlena. If it's like fill_val(), using short varlena saves memory
footprint and disk space.
In TODO, there is a requirement to be implemented:
Allow single-byte header storage for array elements
This patch mo
On 2024/5/16 00:58, Robert Haas wrote:
On Tue, Apr 16, 2024 at 3:16 AM Quan Zongliang wrote:
According to the discussion with Jian He. Use the guc hook to check if
the xid needs to be output. If needed, the statement log can be delayed
to be output.
I appreciate the work that both of you
On 2024/3/11 09:25, Quan Zongliang wrote:
On 2024/3/4 15:48, jian he wrote:
Maybe we can tolerate LOG, first output the query plan then statement.
It is more appropriate to let the extension solve its own problems.
Of course, this change is not easy to implement.
Due to the way XID is
On 2024/3/4 15:48, jian he wrote:
Maybe we can tolerate LOG, first output the query plan then statement.
It is more appropriate to let the extension solve its own problems.
Of course, this change is not easy to implement.
Due to the way XID is assigned, there seems to be no good solution at
On 2024/2/20 19:18, Tomas Vondra wrote:
On 2/20/24 11:11, Quan Zongliang wrote:
Sorry. I forgot to save a file. This is the latest.
On 2024/2/20 18:07, Quan Zongliang wrote:
The Query structure has an increasing number of bool attributes. This
is likely to increase in the future. And
On 2024/2/20 23:45, Tom Lane wrote:
Quan Zongliang writes:
The Query structure has an increasing number of bool attributes. This is
likely to increase in the future. And they have the same properties.
Wouldn't it be better to store them in bits? Common statements don't use
the
Sorry. I forgot to save a file. This is the latest.
On 2024/2/20 18:07, Quan Zongliang wrote:
The Query structure has an increasing number of bool attributes. This is
likely to increase in the future. And they have the same properties.
Wouldn't it be better to store them in bits? C
The Query structure has an increasing number of bool attributes. This is
likely to increase in the future. And they have the same properties.
Wouldn't it be better to store them in bits? Common statements don't use
them, so they have little impact. This also saves memory space.
--
Quan Zongl
Add the GUC parameter.
On 2024/1/30 21:25, Quan Zongliang wrote:
On 2023/11/3 15:27, Quan Zongliang wrote:
Hi
We have one such problem. A table field has skewed data. Statistics:
n_distinct | -0.4481973
most_common_vals | {5f006ca25b52ed78e457b150ee95a30c
A little tweak to the code.
GetTopTransactionIdIfAny() != InvalidTransactionId
changed to
TransactionIdIsValid(GetTopTransactionIdIfAny()
On 2024/1/12 08:51, jian he wrote:
Hi
...
with patch:
src3=# explain(analyze, costs off) select 1 from pg_sleep(10);
2024-01-12 08:43:14.750 CST [5739] ji
On 2023/11/3 15:27, Quan Zongliang wrote:
Hi
We have one such problem. A table field has skewed data. Statistics:
n_distinct | -0.4481973
most_common_vals | {5f006ca25b52ed78e457b150ee95a30c}
most_common_freqs | {0.5518474}
Data generation:
CREATE TABLE s_user
On 2023/11/24 03:39, Pavel Stehule wrote:
I modified the documentation a little bit - we don't need to extra
propose SQL array syntax, I think.
I rewrote regress tests - we don't need to test unsupported
functionality (related to RECORD).
- all tests passed
I wrote two examples of error
On 2023/11/20 17:33, Pavel Stehule wrote:
I did some deeper check:
- I don't like too much parser's modification (I am sending alternative
own implementation) - the SQL parser allows richer syntax, and for full
functionality is only few lines more
Agree.
- original patch doesn't solve
ise.
3.Trace the execution time of the PREPARE statement. When an execution
time is found to be much longer than the average execution time, the
custom plan is forced to run.
Is there any better idea?
--
Quan Zongliang
On 2023/10/17 12:15, Pavel Stehule wrote:
út 17. 10. 2023 v 3:30 odesílatel Quan Zongliang <mailto:quanzongli...@yeah.net>> napsal:
On 2023/10/16 20:05, Pavel Stehule wrote:
>
>
> po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson
mail
On 2023/10/16 20:05, Pavel Stehule wrote:
po 16. 10. 2023 v 13:56 odesílatel Daniel Gustafsson <mailto:dan...@yesql.se>> napsal:
> On 16 Oct 2023, at 12:15, Quan Zongliang mailto:quanzongli...@yeah.net>> wrote:
> Implement TODO item:
> PL/pgSQL
Error messages still seem ambiguous.
do not support multi-dimensional arrays in PL/pgSQL
Isn't that better?
do not support multi-dimensional %TYPE arrays in PL/pgSQL
On 2023/10/17 09:19, Quan Zongliang wrote:
Attached new patch
More explicit error messages based on type.
On
Attached new patch
More explicit error messages based on type.
On 2023/10/16 18:15, Quan Zongliang wrote:
Implement TODO item:
PL/pgSQL
Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
As a first step, deal only with [], such as
xxx.yyy%TYPE[]
xxx%TYPE[]
It can be
Implement TODO item:
PL/pgSQL
Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
As a first step, deal only with [], such as
xxx.yyy%TYPE[]
xxx%TYPE[]
It can be extended to support multi-dimensional and complex syntax in
the future.
--
Quan Zongliangdiff --git a/src/pl/plp
Implement TODO item:
Fix log_line_prefix to display the transaction id (%x) for statements
not in a transaction block
Currently it displays zero.
Check that the XID has been assigned at the location where the statement
log is now printed. If not, no statement log is output.
And then be
On 2023/9/6 17:07, John Naylor wrote:
On Wed, Sep 6, 2023 at 2:50 PM Quan Zongliang <mailto:quanzongli...@yeah.net>> wrote:
> If not optimized(--enable-debug CFLAGS='-O0'), there is a clear
> difference. When the compiler does the optimization, the performance i
On 2023/9/6 15:50, Quan Zongliang wrote:
On 2023/9/5 18:46, John Naylor wrote:
On Tue, Sep 5, 2023 at 4:27 PM Quan Zongliang <mailto:quanzongli...@yeah.net>> wrote:
> Here's how I test it
> EXPLAIN ANALYZE SELECT * FROM orders;
Note that EXPLAIN ANALYZ
On 2023/9/5 18:46, John Naylor wrote:
On Tue, Sep 5, 2023 at 4:27 PM Quan Zongliang <mailto:quanzongli...@yeah.net>> wrote:
> Here's how I test it
> EXPLAIN ANALYZE SELECT * FROM orders;
Note that EXPLAIN ANALYZE has quite a bit of overhead, so it's not good
On 2023/9/5 16:15, John Naylor wrote:
On Thu, Aug 24, 2023 at 5:55 PM Quan Zongliang <mailto:quanzongli...@yeah.net>> wrote:
> In the function heapgetpage. If a table is not updated very frequently.
> Many actions in tuple loops are superfluous. For all_visible pages,
&g
On 2023/6/17 06:46, Tom Lane wrote:
Quan Zongliang writes:
Perhaps we should discard this (dups cnt > 1) restriction?
That's not going to happen on the basis of one test case that you
haven't even shown us. The implications of doing it are very unclear.
In particular, I s
On 2023/6/16 23:39, Tomas Vondra wrote:
On 6/16/23 11:25, Quan Zongliang wrote:
We have a small table with only 23 rows and 21 values.
The resulting MCV and histogram is as follows
stanumbers1 | {0.08695652,0.08695652}
stavalues1 | {v1,v2}
stavalues2 |
{v3,v4,v5,v6,v7,v8,v9,v10,v11,v12
we have the right estimates:
Hash Join (cost=1.52..72100.69 rows=3631 width=0) (actual
time=1.447..1268.385 rows=3902 loops=1)
Regards,
--
Quan Zongliang
Beijing Vastdata Co., LTDdiff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
index 52ef462dba..08ea4243f5 100644
-
On 2023/4/3 19:44, Tomas Vondra wrote:
On 4/3/23 12:23, Quan Zongliang wrote:
Hi,
I found that the enable_hashjoin disables HashJoin completely.
It's in the function add_paths_to_joinrel:
if (enable_hashjoin || jointype == JOIN_FULL)
hash_inner_and_outer(root, joinrel, out
1;
analyze t_student_01;
SET enable_hashjoin TO off;
SET enable_nestloop TO off;
SET enable_mergejoin TO off;
explain select count(*)
from t_student_01 a join t_score_01 b on a.s_id=b.s_id;
After disabling all three, the HashJoin path should still be chosen.
Attached is the patch file.
--
Quan Zongliang
Vas
On 2022/8/17 10:03, Tom Lane wrote:
Quan Zongliang writes:
1. When using extended PGroonga
...
3. Neither ID = 'f' nor id= 't' can use the index correctly.
This works fine for btree indexes. I think the actual problem
is that IsBooleanOpfamily only accepts the btre
= true)
(2 rows)
The reason is that these expressions are converted to BoolExpr and Var.
match_clause_to_indexcol does not use them to check boolean-index.
patch attached.
--
Quan Zongliang
Beijing Vastdatadiff --git a/src/backend/optimizer/path/indxpath.c
b/src/backend/optimizer/path/indxpath
On 2021/7/9 9:50 上午, Michael Paquier wrote:
On Fri, Jul 09, 2021 at 09:26:37AM +0800, Quan Zongliang wrote:
new patch attached
That's mostly fine at quick glance. Here are some comments.
Please add pageinspect--1.9--1.10.sql within the patch. Using git,
you can do that with a simple
On 2021/7/8 3:54 下午, Michael Paquier wrote:
On Wed, Jul 07, 2021 at 11:28:06PM -0500, Justin Pryzby wrote:
I think you can refer to this prior commit for guidance.
commit f18aa1b203930ed28cfe42e82d3418ae6277576d
Author: Peter Eisentraut
Date: Tue Jan 19 10:28:05 2021 +0100
pageinspec
On 2021/7/8 3:54 下午, Michael Paquier wrote:
On Wed, Jul 07, 2021 at 11:28:06PM -0500, Justin Pryzby wrote:
I think you can refer to this prior commit for guidance.
commit f18aa1b203930ed28cfe42e82d3418ae6277576d
Author: Peter Eisentraut
Date: Tue Jan 19 10:28:05 2021 +0100
pageinspe
age('t1',0));
lsn| checksum | flags | lower | upper | special | pagesize |
version | prune_xid
---+--+---+---+---+-+--+-+---
0/19EA640 |0 | 0 |28 | 32736 | 32768 |32768 |
4 | 0
(1 row)
--
Hi,
In the KnownAssignedTransactionIdes sub-module, two lines of unused code
were found in a previous change.
--
Quan Zongliang
CPUG
diff --git a/src/backend/storage/ipc/procarray.c
b/src/backend/storage/ipc/procarray.c
index b448533564..99ce8c752a 100644
--- a/src/backend/storage/ipc
Good.
I tested it, and it looks fine.
Thank you.
On 2020/6/29 1:10 上午, Tom Lane wrote:
I wrote:
Even granting the premise, the proposed patch seems like a significant
decrease in user-friendliness for typical cases. I'd rather see us
make an effort to print one valid-per-the-DB-encoding cha
The bit/varbit type input functions cause file_fdw to fail to read the
logfile normally.
1. Server conf:
server_encoding = UTF8
locale = zh_CN.UTF-8
2. Create external tables using file_fdw
CREATE EXTENSION file_fdw;
CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN
On 2020/1/15 08:30, Quan Zongliang wrote:
On 2020/1/3 17:14, Peter Eisentraut wrote:
On 2019-11-01 04:39, Euler Taveira wrote:
ATExecAlterColumnType records everything that depends on the column
and for indexes it saves the definition (via pg_get_indexdef_string).
Definition is not sufficient
On 2020/1/3 17:14, Peter Eisentraut wrote:
On 2019-11-01 04:39, Euler Taveira wrote:
ATExecAlterColumnType records everything that depends on the column
and for indexes it saves the definition (via pg_get_indexdef_string).
Definition is not sufficient for reconstructing the replica identity
info
On 2019/11/1 20:49, Peter Eisentraut wrote:
On 2019-10-20 00:23, Euler Taveira wrote:
You can probably achieve that using ALTER PUBLICATION to disable
publication of deletes or truncates, as the case may be, either
permanently or just for the duration of the operations you want to skip.
... th
On 2019/10/28 12:39, Kyotaro Horiguchi wrote:
Hello.
# The patch no longer applies on the current master. Needs a rebasing.
New patch, rebased on master branch.
At Sat, 26 Oct 2019 16:50:48 +0800, Quan Zongliang
wrote in
In fact, the replication property of the table has not been
On 2019/10/28 12:39, Kyotaro Horiguchi wrote:
Hello.
# The patch no longer applies on the current master. Needs a rebasing.
At Sat, 26 Oct 2019 16:50:48 +0800, Quan Zongliang
wrote in
In fact, the replication property of the table has not been modified,
and it is still &#
ENTITY. Rebuild and restore replication
settings.
Regards,
Quan Zongliang
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index b53f6ed3ac..c21372fe51 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -
On 2019/9/18 17:11, Peter Eisentraut wrote:
On 2019-09-18 10:39, Quan Zongliang wrote:
Sybase has a feature to turn off replication at the session level: set
replication = off, which can be temporarily turned off when there is a
maintenance action on the table. Our users also want this feature
SERT: col1[integer]:300
COMMIT 494
I'm not sure this is the most appropriate way. What do you think?
Regards,
Quan Zongliang
diff --git a/src/backend/access/transam/xact.c
b/src/backend/access/transam/xact.c
index 9162286c98..d7a04539d6 100644
--- a/src/backend/access/transam/xact.c
+++ b/src
On 2019/9/5 17:33, Pavel Stehule wrote:
čt 5. 9. 2019 v 10:57 odesílatel Quan Zongliang
<mailto:zongliang.q...@postgresdata.com>> napsal:
On 2019/9/5 16:31, Pavel Stehule wrote:
>
>
> čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang
&g
On 2019/9/5 16:31, Pavel Stehule wrote:
čt 5. 9. 2019 v 10:25 odesílatel Quan Zongliang
<mailto:zongliang.q...@postgresdata.com>> napsal:
On 2019/9/5 15:09, Pavel Stehule wrote:
>
>
> čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang
&g
On 2019/9/5 15:09, Pavel Stehule wrote:
čt 5. 9. 2019 v 8:39 odesílatel Quan Zongliang
<mailto:zongliang.q...@postgresdata.com>> napsal:
Dear hackers,
I found that such a statement would get 0 in PL/pgSQL.
PREPARE smt_del(int) AS DELETE FROM t1;
EXECUTE 'E
e a little enhancement. Support for the
number of rows processed when executing INSERT/UPDATE/DELETE statements
dynamically.
Regards,
Quan Zongliang
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index 22dd55c378..b364492e0e 100644
--- a/src/backend/executor/spi.c
+++ b/src/backen
54 matches
Mail list logo
