" and "LC_CTYPE" parameters. I
successfully built the doc in HTML locally.
This patch has been created against the current master branch but it
should equally be applied to REL_16_STABLE and REL_17_STABLE.
Thanks,
Pierre
[1]
https://git.postgresql.org/gitwe
ONLY));
---
> /*
>* econtext = utf_u2e(Tcl_GetVar(interp, "errorInfo",
TCL_GLOBAL_ONLY));
>*/
> econtext = utf_u2e(Tcl_GetStringResult(interp));
gives:
pierre=# CREATE OR REPLACE PROCEDURE test_proc(INOUT a text)
AS $$
set aa [concat $1 "+&quo
On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote:
> On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote:
> > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote:
> >> I ended up writing several patches that shaved some time for
On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote:
> On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote:
> > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote:
> >> I ended up writing several patches that shaved some time for
On Monday, September 18, 2023 11:52:47 PM CEST Nathan Bossart wrote:
> On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote:
> > I ended up writing several patches that shaved some time for pg_restore
> > -l,
> > and reduced the toc.dat size.
>
> I've
ctions that do that in a better
way. And the location of string tables in the file and in the structures is
probably not acceptable, I suppose these should go to the toc header instead.
I still submit these for comments and first review.
Best regards
Pierre Ducroquet
>From cf5afd22a6e754ccf
ing nice speedup opportunities with a huge number of objects.
patched pg_restore + parallel restore of schemas: 10 minutes
Anyway, the patch works really fine as is, and I will certainly keep trying
future iterations.
Regards
Pierre
On Tuesday, July 26, 2022 3:08:01 AM CEST Lukas Fittl wrote:
> On Mon, Jul 25, 2022 at 12:38 AM Pierre Ducroquet
>
> wrote:
> > usecase by not showing the schema, one of them being log_line_prefix.
> > It is possible to work around this using the application_name, but a
&
On Monday, July 25, 2022 11:52:41 AM CEST Alvaro Herrera wrote:
> On 2022-Jul-25, Pierre Ducroquet wrote:
> > This is great for performance, but several tools are lacking around this
> > usecase by not showing the schema, one of them being log_line_prefix.
> >
> > Th
more "generic" method should be used (I thought of %{name} to fetch an
arbitrary GUC, but did not implement due to a lack of need for that feature)
>From d28ea4452c6e78bf8e67db49d1c72dbf4bd1ca48 Mon Sep 17 00:00:00 2001
From: Pierre Ducroquet
Date: Mon, 25 Jul 2022 09:33:49 +0200
Subj
Thanks! I'll also try to review it next week.
>
>>> https://commitfest.postgresql.org/30/2765/
>>>
>>> I will review the code next week. Unfortunately, I cannot give any
>>> feedback about usability of this feature.
>>>
>>> User
gt; Attached is the updated version of the patch.
>>>> I also added the regression test performing "explain (buffers on)"
>>>> without "analyze" option.
>>>
>>> Looks good to me.
>>
>> Looks good to me too.
>
> David and Jul
Can you please show what the plan would look like for?
=# explain (buffers on, summary on, format JSON) select * from t;
Le 20/08/2020 à 09:58, Fujii Masao a écrit :
>
>
> On 2020/08/20 13:00, David Rowley wrote:
>> On Thu, 20 Aug 2020 at 03:31, Fujii Masao
>> wrote:
>>> With the patch, for
Le 07/08/2020 à 14:52, Julien Rouhaud a écrit :
> Hi,
>
> On Fri, Aug 7, 2020 at 2:30 PM Pierre Giraud wrote:
>>
>> Hi all,
>>
>> As far as I understand, in the upcoming version 13, information about
>> buffers used during planning is now ava
lanning Time: 0.203 ms
Buffers: shared hit=14
[…]
Note: a similar way to format information is already used for JIT.
[…]
JIT:
Functions: 3
Options: Inlining false, Optimization false, Expressions true,
Deforming true
Timing: Generation 0.340 ms, Inlining 0.000 ms, Optimization 0.168
ms, Emission 1.907 ms, Total 2.414 ms
[…]
Regards,
Pierre
TINCT clause
fields. If it is possible to optimize, we then iterate through the JOINs.
Any comment on this would be more than welcome!
Regards
Pierre
>From bc71aea5a0c1911c1f63567c21a870241b76231b Mon Sep 17 00:00:00 2001
From: Pierre Ducroquet
Date: Fri, 31 Jul 2020 10:28:25
Le 16/04/2020 à 16:43, Tom Lane a écrit :
> Pierre Giraud writes:
>> Le 16/04/2020 à 00:18, Tom Lane a écrit :
>>> The main disadvantage I can see to the v2 design is that we're back
>>> to having two per function, which is inevitably going to result
>&
Le 16/04/2020 à 00:18, Tom Lane a écrit :
> As I threatened to do earlier, I made a pass at converting table 9.10
> to a couple of the styles under discussion. (This is just a
> draft-quality patch, so it might have some minor bugs --- the point
> is just to see what these styles look like.)
>
On Saturday, February 1, 2020 3:24:46 PM CET Tomas Vondra wrote:
> On Sat, Feb 01, 2020 at 08:51:04AM +0100, Pierre Ducroquet wrote:
> >Hello
> >
> >At my current job, we have a lot of multi-tenant databases, thus with
> >tables containing a tenant_id column. Such a
ude array contains.
I tested the patches on current HEAD, but I can test and provide back-ported
versions of the patch for other versions if needed (this code path hardly
changed since its introduction in 10).
Best regards
Pierre Ducroquet
>From d2b89748e1b520c276875538149eb466e97c21b4 Mon Sep
On Monday, January 6, 2020 6:57:33 PM CET Tom Lane wrote:
> Pierre Ducroquet writes:
> > Attached to this email is a patch with better comments regarding the
> > XLogSendLogical change.
>
> Hi,
> This patch entirely fails to apply for me (and for the cfbot too).
On Sunday, December 29, 2019 1:32:31 PM CET Julien Rouhaud wrote:
> On Sat, Dec 28, 2019 at 1:56 PM Pierre Ducroquet
wrote:
> > Thank you for your comments.
> > Attached to this email is a patch with better comments regarding the
> > XLogSendLogical change.
>
>
On Thursday, December 26, 2019 8:18:46 PM CET Julien Rouhaud wrote:
> Hello Pierre,
>
> On Thu, Dec 26, 2019 at 5:43 PM Pierre Ducroquet
wrote:
> > The second one was tested on PG 10 and PG 12 (with 48 lines offset). It
> > has on PG12 the same effect it has on a PG10+isAl
Hello
Our current setup uses logical replication to build a BI replication server
along our primary clusters (running PG 10.10 so far). This implies having one
logical replication slot per database. After some analysis, we identified two
hot spots behind this issue. Fixing them gave us a 10 fol
iven AND clause. But compared to the possible benefits, and
the very low risk of n being high enough to have a real planification-time
impact, I feel this optimization would be worth it.
Regards
Pierre
>From 0a300b6fdd934daa6fb79e9bc67bdc2adfa3cc72 Mon Sep 17 00:00:00 2001
From: Pierre Ducro
On Monday, September 2, 2019 3:25:00 AM CEST Euler Taveira wrote:
> Em dom, 1 de set de 2019 às 06:04, Pierre Ducroquet
>
> escreveu:
> > Hello
> >
> > pg_stat_statements is a great tool to track performance issue in live
> > databases, especially when adding
On Tuesday, September 3, 2019 12:39:51 PM CEST Kuntal Ghosh wrote:
> Hello Pierre,
Hello Kuntal
>
> > When using a functional index on a table, we realized that the permission
> > check done in pg_stats was incorrect and thus preventing valid access to
> > the statistics
aforementioned scenario.
Regards
Pierre Ducroquet>From 5e6d16d738e5279968321c5f3695e72ded2432db Mon Sep 17 00:00:00 2001
From: Pierre
Date: Thu, 14 Feb 2019 14:37:48 +0100
Subject: [PATCH] Add a function to reset the cumulative statistics
pg_stat_statements has two parts : raw statistics that are sim
Hi,
I'm currently working on a tool to visualize an execution plan [1]. For
those who know PEV, it's actually a fork of this great tool since it
hasn't been active for more than 2 years.
Among other things, I'd like to show information for the parallel
queries. First of which is information about
patch fixes this by introducing a second path in privilege check
in pg_stats view.
I have not written a regression test yet, mainly because I'm not 100% certain
where to write it. Given some hints, I would happily add it to this patch.
Regards
Pierre Ducroquet
>From c2f638a9491e10331116
On Wednesday, February 20, 2019 5:24:17 PM CET Tom Lane wrote:
> Pierre Ducroquet writes:
> > For simple functions like enum_eq/enum_ne, marking them leakproof is an
> > obvious fix (patch attached to this email, including also textin/textout).
>
> This is not nearly as &
On Wednesday, February 20, 2019 12:43:50 AM CET Laurenz Albe wrote:
> Pierre Ducroquet wrote:
> > In order to increase our security, we have started deploying row-level
> > security in order to add another safety net if any issue was to happen in
> > our applications
responding
patches.
Best regards
>From a4dd6eb9a16e7e2d2e44b03c5a04c485841aab25 Mon Sep 17 00:00:00 2001
From: Pierre Ducroquet
Date: Tue, 19 Feb 2019 17:21:12 +0100
Subject: [PATCH] Mark textin/out and enum_eq/ne as leakproof
---
src/include/catalog/pg_proc.dat | 8
1 file changed,
On Thursday, October 4, 2018 4:46:26 PM CEST Geoff Winkless wrote:
> On Thu, 4 Oct 2018 at 13:11, Pierre Ducroquet wrote:
> > Our developpers ORM (Django's) sadly can not use EXISTS in the where
> > clauses
> > without having it in the expression part of the SELECT state
(cost=0.00..25.00 rows=6 width=0)
Filter: (a_id = a.id)
SubPlan 2
-> Seq Scan on b b_2 (cost=0.00..22.00 rows=1200 width=4)
(12 rows)
Thanks
Pierre
dentify_object_as_address(classId, ObjId, objSubId)).*
from pg_depend where classId <> 0;
Thanks,
Jean-Pierre Pelletier
Awesome, thanks!
Le ven. 31 août 2018 16:46, Tom Lane a écrit :
> I wrote:
> > Not sure if this rises to the level of a back-patchable bug.
> > People might be surprised if we change that output in minor releases.
> > But we could still squeeze it into v11, I think.
>
> I pushed a fix into HEAD
Btw, pg_dump is handling this right.
Jean-Pierre Pelletier
Le ven. 31 août 2018 10:33, Tom Lane a écrit :
> "jean.pierre.pelletier0" writes:
> > To reproduce, compare the output of \dC on two built-in casts(json to
> jsonb) and (xml to text) where only the the first
On Wednesday, August 22, 2018 6:51:55 PM CEST Andres Freund wrote:
> On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote:
> > Just to be clear; The query really runs slower (wall-clock time), it's not
> > just the timing.
>
> I bet it's not actually running slower, it "just" takes longer to s
On Friday, July 13, 2018 11:08:45 PM CEST Andres Freund wrote:
> Hi,
>
> Thanks for looking at this!
>
> On 2018-07-13 10:20:42 +0200, Pierre Ducroquet wrote:
> > 2) improve the LLVM IR code
> >
> > The code generator in llvmjit-deform.c currently rely on the L
ence it in lca_inner.
The attached basic patch fixes it.
Regards
Pierre
>From 4e59747cea428d39c80974c408e95ba86bf63ecc Mon Sep 17 00:00:00 2001
From: Pierre Ducroquet
Date: Fri, 13 Jul 2018 12:47:36 +0200
Subject: [PATCH] Fix segfault with lca('{}'::ltree[])
---
contrib/ltree/
00:00:00 2001
From: Pierre Ducroquet
Date: Wed, 11 Jul 2018 23:41:59 +0200
Subject: [PATCH 1/2] Check for the hasnulls attribute before checking
individual fields
---
src/backend/jit/llvm/llvmjit_deform.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/sr
e results are :
- no jit : 850ms
- jit with tuple deforming without optimizations : 1650 ms (1.5ms spent
optimizing)
- jit without tuple deforming : 820ms (0.2ms)
- jit with tuple deforming with optimization (-O3) : 770ms (105ms)
- jit with tuple deforming with patch (-O1) : 725ms (54ms)
I will
On Fri, May 25, 2018 at 02:37:52PM +0200, Pierre-Emmanuel André wrote:
> On Thu, May 24, 2018 at 01:03:00PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2018-05-24 21:47:27 +0200, Pierre-Emmanuel André wrote:
> > > Hello,
> > >
> > > I'm t
On Monday, May 28, 2018 4:37:06 AM CEST Yuriy Zhuravlev wrote:
> > Can't see getting rid of those entirely. None of the github style
> > platforms copes with reasonable complex discussions.
>
> I disagree. A good example of complex discussions on github is Rust
> language tracker for RFCs:
> https
Hello,
I'm the maintainer of PostgreSQL on OpenBSD.
Today I tried the beta1 of PostgreSQL 11 on OpenBSD -current @amd64.
Without JIT, everything works fine.
When i enable JIT, regress tests fail with this error :
indexing ... FAILED (test process exited with exit code 2)
l
great new feature of v11 I was
not aware of. But psql saw the addition of \if recently, so why not having
loops in there too ? (Something better than this hack of course, it was just a
10 minutes hack-sprint for a demo)
Regards
Pierre
Hi
When running database migrations with .sql files on a live database, it's not
uncommon to have to run a migration in a loop to prevent a big lock on a
table.
For instance if one want to delete some old datas from a big table one would
write :
DELETE FROM big_table WHERE id IN (SELECT id FRO
prised that llvm-lto is invoked in the "make install" stage.
> I would expect it to be done by plain "make" already, and "make install"
> would just copy the files to the right places.
Hi
The bitcode format does not respect strict compatibility rules. LLVM and clang
versions must match if we don't want any surprise.
See for instance
https://stackoverflow.com/questions/15836430/how-stable-is-the-llvm-assembly-language
In your case, this should have worked, but I am not surprised at all that this
failed, I had similar issues when testing 3.9/4.0 on the same system. I
thought the build system already checked for version equality.
Pierre
On Thursday, March 29, 2018 2:39:17 PM CEST Jesper Pedersen wrote:
> Hi Andres,
>
> On 03/28/2018 05:27 PM, Andres Freund wrote:
> > On 2018-03-27 10:34:26 -0700, Andres Freund wrote:
> >> On 2018-03-27 10:05:47 -0400, Peter Eisentraut wrote:
> >>> On 3/13/18 19:40, Andres Freund wrote:
> I'v
On Friday, March 2, 2018 2:44:16 PM CET David Steele wrote:
> Hi Pierre,
>
> On 3/2/18 6:36 AM, Pierre Ducroquet wrote:
> > While working on a big table recently, I noticed that ALTER TABLE does not
> > check for column existence in operations like SET NOT NULL before starti
are left to the exec code to exclude.
The patch has been checked with make check, and I see no documentation change
to do since this does not alter any existing documented behaviour.
Regards
Pierre
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 74e020bff
hlib looks now. I'm
> planning to work on cleaning and then pushing some of the preliminary
> patches (fixed tupledesc, grouping) over the next few days.
>
> Greetings,
>
> Andres Freund
Hi
Here are the LLVM4 and LLVM3.9 compatibility patches.
Successfully built, and
l addition to the gitignore file, I'm surprised you were not
bothered by the various .bc files generated.
Anyway, great work, and I look forward exploring the code :)
Pierre
>From f461c3d6d0deec52b66f3276a87cfdb3ab65b259 Mon Sep 17 00:00:00 2001
From: Pierre
Date: Fri, 2
On Monday, February 5, 2018 10:20:27 PM CET Andreas Karlsson wrote:
> OK that fixed the issue, but you have a typo in your patch set.
>
> diff --git a/src/backend/lib/llvmjit_inline.cpp
> b/src/backend/lib/llvmjit_inline.cpp
> index a785261bea..51f38e10d2 100644
> --- a/src/backend/lib/llvmjit_inl
On Sunday, February 4, 2018 12:45:50 AM CET Andreas Karlsson wrote:
> On 02/02/2018 10:48 AM, Pierre Ducroquet wrote:
> > I have successfully built the JIT branch against LLVM 4.0.1 on Debian
> > testing. This is not enough for Debian stable (LLVM 3.9 is the latest
> > availab
On Sunday, February 4, 2018 12:45:50 AM CET Andreas Karlsson wrote:
> On 02/02/2018 10:48 AM, Pierre Ducroquet wrote:
> > I have successfully built the JIT branch against LLVM 4.0.1 on Debian
> > testing. This is not enough for Debian stable (LLVM 3.9 is the latest
> > availab
On Friday, February 2, 2018 10:48:16 AM CET Pierre Ducroquet wrote:
> On Monday, January 29, 2018 10:53:50 AM CET Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-23 23:20:38 -0800, Andres Freund wrote:
> > > == Code ==
> > >
> > > As the patchset
t three fix the build issues, the
last one fixes a runtime issue.
I think they are small enough to not be a burden for you in your developments.
But if you don't want to carry these ifdefs right now, I maintain them in a
branch on a personal git and rebase as frequently as I can.
LLVM 3.9 suppor
On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote:
> > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM
> > documentation is really lacking when it comes to porting from version x
>
one major LLVM release, as was
suggested in another thread ?
Pierre
On Thursday, January 25, 2018 8:12:42 PM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote:
> > I don't know when this would be released,
>
> August-October range.
>
> > but the minimal supported LLVM
> > ve
On Thursday, January 25, 2018 7:38:16 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-24 22:33:30 -0800, Jeff Davis wrote:
> > On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet
wrote:
> > > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only
> &
ry’ has no member
named ‘getBaseObject’
fs = llvm::cast(gvs->getBaseObject());
^
That one was a bit uglier.
I'm not sure how to test everything properly, so the patch is attached for
both these issues, do as you wish with it… :)
Regards
Pierre Ducroquet
>From fdfea09dd7410d6ed7ad54df1ba3
64 matches
Mail list logo
