At Wed, 14 Jun 2023 15:46:08 -0700, Nathan Bossart
wrote in
> On Wed, Jun 14, 2023 at 03:11:54PM -0700, Noah Misch wrote:
> > Here's some output from this program (on AIX 7.1, same output when compiled
> > 32-bit or 64-bit):
> >
> > $ ./a.out a b c d e f
> > f e d c b a ./a.out
>
> Thanks
On Thu, Jun 15, 2023 at 2:51 PM Vladimir Churyukin
wrote:
> Do you foresee any difficulties in implementation of the "unwarm" operation?
> It requires a cache flush operation,
> so I'm curious how complicated that is (probably there is a reason this is
> not supported by Postgres by now? mssql
On Mon, 2023-06-12 at 23:04 +0200, Peter Eisentraut wrote:
> I object to adding a new provider for PG16 (patch 0001).
Added to July CF for 17.
> > 2. Patch 0004 is possibly out of scope for 16
> Also clearly a new feature.
Added to July CF for 17.
Regards,
Jeff Davis
Currently, CREATE COLLATION always defaults the provider to libc.
The attached patch causes it to default to libc if LC_COLLATE/LC_CTYPE
are specified, otherwise default to the current database default
collation's provider.
That way, the provider choice at initdb time then becomes the default
Mmm. It seems like the email I thought I'd sent failed to go out.
At Sun, 11 Jun 2023 07:14:54 +0530, Bharath Rupireddy
wrote in
> On Wed, Aug 24, 2022 at 6:42 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 16 Aug 2022 18:40:49 +0200, Alvaro Herrera
> > wrote in
> > > On 2022-Aug-16, Andrew
On Thu, Jun 15, 2023 at 5:04 AM Joel Jacobson wrote:
> On Wed, Jun 14, 2023, at 15:16, Tomas Vondra wrote:
> > On 6/14/23 14:57, Joel Jacobson wrote:
> >> Would it be feasible to teach the planner to utilize the internal hash
> table of
> >> hashset directly? In the case of arrays, the hash
On Thu, Jun 15, 2023 at 09:46:33AM +0900, Michael Paquier wrote:
> The result after 0001 is applied is that a couple of
> object_ownercheck() calls that existed before ff9618e are removed from
> some ACL checks in the REINDEX, CLUSTER and VACUUM paths. Is that OK
> for shared relations and
It could be cheaper, if the testing is done for many SELECT queries
sequentially - you need to flush dirty buffers just once pretty much.
-Vladimir Churyukin
On Wed, Jun 14, 2023 at 7:43 PM Tom Lane wrote:
> Thomas Munro writes:
> > There are two levels of cache. If you're on Linux you can
Do you foresee any difficulties in implementation of the "unwarm"
operation? It requires a cache flush operation,
so I'm curious how complicated that is (probably there is a reason this is
not supported by Postgres by now? mssql and oracle support stuff like that
for a long time)
Cluster restart
On Wed, Jun 14, 2023 at 6:52 PM Peter Eisentraut wrote:
>
> On 14.06.23 05:09, Amit Kapila wrote:
> > The latest version looks good to me as well. I think we should
> > backpatch this change as this is a user-facing message change in docs
> > and code. What do you guys think?
>
> Isn't that a
Thomas Munro writes:
> There are two levels of cache. If you're on Linux you can ask it to
> drop its caches by writing certain values to /proc/sys/vm/drop_caches.
> For PostgreSQL's own buffer pool, it would be nice if someone would
> extend the pg_prewarm extension to have a similar 'unwarm'
Hi,
There are different types of Logical Replication workers -- e.g.
tablesync workers, apply workers, and parallel apply workers.
The logging and errors often name these worker types, but during a
recent code review, I noticed some inconsistency in the way this is
done:
a) there is a common
On Thu, Jun 15, 2023 at 1:37 PM Vladimir Churyukin
wrote:
> Ok, got it, thanks.
> Is there any alternative approach to measuring the performance as if the
> cache was empty?
There are two levels of cache. If you're on Linux you can ask it to
drop its caches by writing certain values to
On Thu, Jun 15, 2023 at 5:04 AM Joel Jacobson wrote:
> On Wed, Jun 14, 2023, at 15:16, Tomas Vondra wrote:
> > On 6/14/23 14:57, Joel Jacobson wrote:
> >> Would it be feasible to teach the planner to utilize the internal hash
> table of
> >> hashset directly? In the case of arrays, the hash
At Wed, 14 Jun 2023 14:36:54 +0200, Antonin Houska wrote in
> Like in cost_seqscan(), I'd expect the subpath cost to be divided among
> parallel workers. The patch below shows what I mean. Am I right?
If I've got it right, the total cost of a partial seqscan path
comprises a distributed CPU run
On Wed, Jun 14, 2023 at 4:47 PM Michael Paquier wrote:
>
> On Wed, Jun 14, 2023 at 03:38:10PM +0800, Richard Guo wrote:
> > +1. BTW, it seems that GUC_UNIT_TIME is not used anywhere except in
> > GUC_UNIT. I was wondering if we can retire it, but maybe we'd better
> > not. It still indicates
Ok, got it, thanks.
Is there any alternative approach to measuring the performance as if the
cache was empty?
The goal is basically to calculate the max possible I/O time for a query,
to get a range between min and max timing.
It's ok if it's done during EXPLAIN ANALYZE call only, not for regular
Vladimir Churyukin writes:
> There is often a need to test particular queries executed in the worst-case
> scenario, i.e. right after a server restart or with no or minimal amount of
> data in shared buffers. In Postgres it's currently hard to achieve (other
> than to restart the server
To be clear, I'm talking about bypassing shared buffers for reading data /
indexes only, not about disabling it completely (which I guess is
impossible anyway).
-Vladimir Churyukin
On Wed, Jun 14, 2023 at 5:57 PM Vladimir Churyukin
wrote:
> Hello,
>
> There is often a need to test particular
Hello,
There is often a need to test particular queries executed in the worst-case
scenario, i.e. right after a server restart or with no or minimal amount of
data in shared buffers. In Postgres it's currently hard to achieve (other
than to restart the server completely to run a single query,
On Wed, Jun 14, 2023 at 11:17:11AM -0700, Nathan Bossart wrote:
> On Tue, Jun 13, 2023 at 04:54:42PM -0700, Nathan Bossart wrote:
> > On Wed, Jun 14, 2023 at 08:16:15AM +0900, Michael Paquier wrote:
> >> So, yes, agreed about the removal of has_partition_ancestor_privs().
> >> I am adding an open
On Wed Jun 14, 2023 at 2:32 PM CDT, Andres Freund wrote:
> Hi,
>
> On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
> > On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
> > > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
> > > > Hi,
> > > >
> > > > On 2023-06-02 08:10:43 -0500,
On Wed, 14 Jun 2023 at 19:14, Tomas Vondra
wrote:
> > ...So we'd want the same index usage as
> > =ANY(array) but would like faster row checking than we get with an array
> > when other indexes are used.
>
> We kinda already do this since PG14 (commit 50e17ad281), actually. If
> the list is long
On Wed, Jun 14, 2023 at 10:50 PM Juan José Santamaría Flecha
wrote:
> Yes, I think the situation is quite similar to what you describe, with its
> WIN32 peculiarities. Take for example the attached program, it'll output:
>
> s1 = s2
> s2 = s3
> s1 > s3
> c1 > c2
> c2 > c3
> c1 > c3
>
> As you
On Thu, Jun 15, 2023 at 10:55 AM Jeff Davis wrote:
> The locale "C" (and equivalently, "POSIX") is not really a libc locale;
> it's implemented internally with memcmp for collation and
> pg_ascii_tolower, etc., for ctype.
>
> The attached patch implements a new collation provider, "builtin",
>
The locale "C" (and equivalently, "POSIX") is not really a libc locale;
it's implemented internally with memcmp for collation and
pg_ascii_tolower, etc., for ctype.
The attached patch implements a new collation provider, "builtin",
which only supports "C" and "POSIX". It does not change the
On Wed, Jun 14, 2023 at 03:11:54PM -0700, Noah Misch wrote:
> Here's some output from this program (on AIX 7.1, same output when compiled
> 32-bit or 64-bit):
>
> $ ./a.out a b c d e f
> f e d c b a ./a.out
Thanks again.
> Interesting discussion here, too:
>
On Tue, 13 Jun 2023 at 07:55, Konstantin Knizhnik wrote:
>
>
>
> On 12.06.2023 3:23 PM, Pavel Borisov wrote:
> > Is the following true or not?
> >
> > 1. If we switch processes to threads but leave the amount of session
> > local variables unchanged, there would be hardly any performance gain.
>
On Wed, 14 Jun 2023 at 20:48, Robert Haas wrote:
>
> On Wed, Jun 14, 2023 at 3:16 PM James Addison wrote:
> > I think that they're practical performance-related questions about the
> > benefits of performing a technical migration that could involve
> > significant development time, take years to
On Wed, Jun 14, 2023 at 02:28:16PM -0700, Nathan Bossart wrote:
> On Tue, Jun 13, 2023 at 05:17:37PM -0700, Noah Misch wrote:
> > If you have a test program to be run, I can run it on AIX.
>
> Thanks. The patch above [0] adjusts 040_createuser.pl to test modifying
> argv, so that's one test
On Tue, Jun 13, 2023 at 05:17:37PM -0700, Noah Misch wrote:
> If you have a test program to be run, I can run it on AIX.
Thanks. The patch above [0] adjusts 040_createuser.pl to test modifying
argv, so that's one test program. And here's a few lines for reversing
argv:
#include
On Wed, Jun 14, 2023, at 15:16, Tomas Vondra wrote:
> On 6/14/23 14:57, Joel Jacobson wrote:
>> Would it be feasible to teach the planner to utilize the internal hash table
>> of
>> hashset directly? In the case of arrays, the hash table construction is an
...
> It's definitely something I'd
Hi,
On 2023-06-14 16:10:38 -0400, Robert Haas wrote:
> On Wed, Jun 14, 2023 at 3:47 PM Andres Freund wrote:
> > Could we just recompute the WAL summary for the [redo, end of chunk] for the
> > relevant summary file?
>
> I'm not understanding how that would help. If we were going to compute
> a
On Wed, 14 Jun 2023 at 20:47, Robert Haas wrote:
>
> A few years ago, I sketched out a design for incremental backup, but
> no patch for incremental backup ever got committed. Instead, the whole
> thing evolved into a project to add backup manifests, which are nice,
> but not as nice as
On Wed, Jun 14, 2023 at 3:47 PM Andres Freund wrote:
> I assume this is "solely" required for keeping the incremental backups as
> small as possible, rather than being required for correctness?
I believe so. I want to spend some more time thinking about this to
make sure I'm not missing
On Wed, Jun 14, 2023 at 3:46 PM Hannu Krosing wrote:
> I remember a few times when memory leaks in some PostGIS packages
> cause slow memory exhaustion and the simple fix was limiting
> connection lifetime to something between 15 min and an hour.
>
> The main problem here is that PostGIS uses a
Hi,
On 2023-06-11 14:41:27 +0200, Tomas Vondra wrote:
> While testing some stuff, I noticed heapam_estimate_rel_size (or rather
> table_block_relation_estimate_size it calls) ignores fillfactor, so that
> for a table without statistics it ends up with reltuple estimate much
> higher than reality.
Hi,
On 2023-06-13 16:55:12 +0900, Kyotaro Horiguchi wrote:
> At Tue, 13 Jun 2023 09:55:36 +0300, Konstantin Knizhnik
> wrote in
> > Postgres backend is "thick" not because of large number of local
> > variables.
> > It is because of local caches: catalog cache, relation cache, prepared
> >
Hi hackers,
The attached v40 patch is a fresh rebase on master branch to actualize the
state before the upcoming commitfest.
Nothing has changed beyond rebasing.
And just for convenience, here is a link to the exact message of the thread
describing the current approach:
On Wed, Jun 14, 2023 at 3:16 PM James Addison wrote:
> I think that they're practical performance-related questions about the
> benefits of performing a technical migration that could involve
> significant development time, take years to complete, and uncover
> problems that cause reliability
Hi,
On 2023-06-14 14:46:48 -0400, Robert Haas wrote:
> A few years ago, I sketched out a design for incremental backup, but
> no patch for incremental backup ever got committed. Instead, the whole
> thing evolved into a project to add backup manifests, which are nice,
> but not as nice as
On Tue, Jun 13, 2023 at 9:55 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 13 Jun 2023 09:55:36 +0300, Konstantin Knizhnik
> wrote in
> > Postgres backend is "thick" not because of large number of local
> > variables.
> > It is because of local caches: catalog cache, relation cache, prepared
> >
Hi,
On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
> On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
> > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
> > > > > I wonder if we instead could just make perl
On Mon, 12 Jun 2023 at 20:24, Andres Freund wrote:
>
> Hi,
>
> On 2023-06-12 16:23:14 +0400, Pavel Borisov wrote:
> > Is the following true or not?
> >
> > 1. If we switch processes to threads but leave the amount of session
> > local variables unchanged, there would be hardly any performance
>
> So maybe we should make table_block_relation_estimate_size smarter to
> also consider the fillfactor in the "no statistics" branch, per the
> attached patch.
>
I like this a lot. The reasoning is obvious, the fix is simple,it doesn't
upset any make-check-world tests, and in order to get a
On Tue, 2023-06-13 at 14:12 -0700, Nathan Bossart wrote:
> I've been reviewing ff9618e lately, and I'm wondering whether it has
> the
> same problem that 19de0ab solved. Specifically, ff9618e introduces
> has_partition_ancestor_privs(), which is used to check whether a user
> has
> MAINTAIN on
On Tue, Jun 13, 2023 at 04:54:42PM -0700, Nathan Bossart wrote:
> On Wed, Jun 14, 2023 at 08:16:15AM +0900, Michael Paquier wrote:
>> So, yes, agreed about the removal of has_partition_ancestor_privs().
>> I am adding an open item assigned to you and Jeff.
>
> Thanks. I suspect there's more
Hi,
On 2023-06-14 12:40:18 +0700, John Naylor wrote:
> On Sat, Nov 5, 2022 at 3:27 PM Andres Freund wrote:
>
> >/*
> > * Make huge pages out of it. Requires at least linux 6.1. We
> could
> > * fall back to MADV_HUGEPAGE if it fails, but it doesn't do all
> that
> >
On Tue, Jun 13, 2023 at 11:53 AM James Coleman wrote:
>
> ...
> I'm going to re-run tests with my patch version + resetting the flag
> on SIGINT (and any other error condition) to be certain that the issue
> you uncovered (where backends get stuck after a SIGINT not responding
> to the requested
On Wed, Jun 14, 2023 at 5:12 AM Ranier Vilela wrote:
>
> Em qua., 14 de jun. de 2023 às 06:51, Richard Guo
> escreveu:
>>
>>
>> On Tue, Jun 13, 2023 at 3:39 PM Kyotaro Horiguchi
>> wrote:
>>>
>>> Gurjeet has mentioned that eb.rel cannot be modified by another
>>> process since the value or
Again, I forget to actually attach. Holy guacamole.
--
Tristan Partin
Neon (https://neon.tech)
From 8c4eb4849b1282f1a0947ddcf3f599e384a5a428 Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Tue, 23 May 2023 09:21:55 -0500
Subject: [PATCH v2 1/2] Move constant into format string
If we are
On 6/14/23 15:39, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, June 14, 2023 5:05 PM Tomas Vondra
> wrote:
>> ...
>>
>> Also, can you try if we still stream the partial transaction with
>> create_logical_replication_slot building a full snapshot?
>
> Yes, It can fix this problem because force
Here is a v2. It cleans up the output when printing to a tty. The
last "x of y tuples" line gets overwritten now, so the final output
looks like:
dropping old tables...
creating tables...
generating data (client-side)...
vacuuming...
creating primary keys...
done in 0.14 s (drop tables 0.01 s,
On 2023-06-14 We 05:44, Tomas Vondra wrote:
The thing is, adding stuff to core is not free - it means the community
becomes responsible for maintenance, testing, fixing issues, etc. It's
not feasible (or desirable) to have all extensions in core, and cloud
vendors generally do have ways to
On Wed, 14 Jun 2023 at 17:52, Richard Guo wrote:
> On Wed, Jun 14, 2023 at 3:47 PM Michael Paquier wrote:
>
>> On Wed, Jun 14, 2023 at 03:38:10PM +0800, Richard Guo wrote:
>> > +1. BTW, it seems that GUC_UNIT_TIME is not used anywhere except in
>> > GUC_UNIT. I was wondering if we can retire
On Wednesday, June 14, 2023 5:05 PM Tomas Vondra
wrote:
> On 6/14/23 05:15, Zhijie Hou (Fujitsu) wrote:
> > On Tuesday, June 13, 2023 12:19 PM Zhijie Hou (Fujitsu)
> wrote:
> >>
> >> On Tuesday, June 13, 2023 12:04 PM Amit Kapila
> >>
> >> wrote:
> >>>
> >>> On Wed, Jun 7, 2023 at 6:02 PM
On 14.06.23 05:09, Amit Kapila wrote:
The latest version looks good to me as well. I think we should
backpatch this change as this is a user-facing message change in docs
and code. What do you guys think?
Isn't that a reason *not* to backpatch it?
On 6/14/23 14:57, Joel Jacobson wrote:
> On Wed, Jun 14, 2023, at 11:44, Tomas Vondra wrote:
>>> Perspective from a potential user: I'm currently working on something
>>> where an array-like structure with fast membership test performance
>>> would be very useful. The main type of query is
Richard Guo writes:
> I just realized that we may still have holes in this area. Until now
> we're mainly focusing on LATERAL subquery, in which case the lateral
> reference Vars are copied into rel->subplan_params and we've already
> adjusted the nulling bitmaps there. But what about the
On Wed, Jun 14, 2023, at 11:44, Tomas Vondra wrote:
>> Perspective from a potential user: I'm currently working on something
>> where an array-like structure with fast membership test performance
>> would be very useful. The main type of query is doing an =ANY(the set)
>> filter, where the set
Like in cost_seqscan(), I'd expect the subpath cost to be divided among
parallel workers. The patch below shows what I mean. Am I right?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index
On 6/14/23 12:51, Amit Langote wrote:
Ah, did think it might be moderation. Thanks for the confirmation,
Michael.
It’s out now:
https://www.postgresql.org/message-id/E1q9Gms-001h5g-8Q%40gemulon.postgresql.org
Hello,
Just wanted to give a heads up that I am moving to a new role outside
Linaro and as a result wouldn't be able to continue contributing.
Anthony Roberts from Linaro is going to support the enablement work.
--
Niyas
Em qua., 14 de jun. de 2023 às 06:51, Richard Guo
escreveu:
>
> On Tue, Jun 13, 2023 at 3:39 PM Kyotaro Horiguchi
> wrote:
>
>> Gurjeet has mentioned that eb.rel cannot be modified by another
>> process since the value or memory is in the local stack, and I believe
>> he's correct.
>>
>> If the
Hi Nathan,
> > That being said, I still don't understand why you focus on this tiny and not
> > really important detail while the module itself is actually broken (for
> > dynamic
> > bgworker without s_p_l) and also has some broken behaviors with regards to
> > the
> > naptime that are way
On 2023-06-12 Mo 19:43, Nathan Bossart wrote:
On Tue, Jun 13, 2023 at 08:29:19AM +0900, Michael Paquier wrote:
I am actually a bit confused with the return value of
CreateRestrictedProcess() on failures in restricted_token.c. Wouldn't
it be cleaner to return INVALID_HANDLE_VALUE rather than 0
Hi,
> > I have a question for the community - why was this patch silently put to a
> > "rejected" status?
> > Should there no be some kind of explanation?
I wouldn't say that it happened "silently" nor that the reason is so
mysterious [1].
[1]:
On Wed, Jun 14, 2023 at 15:49 Amit Langote wrote:
> On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote:
>
>> On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote:
>> > This being my first commit, I intently looked to check if everything’s
>> set
>> > up correctly. While it seemed to
On Wed, Jun 14, 2023 at 4:13 AM Peter Geoghegan wrote:
> On Tue, Jun 13, 2023 at 5:59 PM Thomas Munro
> wrote:
> > Trying to follow along here... you're doing the moral equivalent of
> > strxfrm(), so sort keys have the transitive property but direct string
> > comparisons don't? Or is this
Hi:
postgres ODBC's driver psqlodbcw.so supports Unicode. You can do this by
checking the value of the SQL_ATTR_ANSI_APP attribute; if it is SQL_AA_FALSE,
Unicode is supported; If the value is SQL_AA_TRUE, ANSI is supported
At 2023-06-14 11:54:46, "Peter Smith" wrote:
>On
On Wed, 14 Jun 2023 at 14:05, Nikita Malakhov wrote:
>
> Hi!
>
> I have a question for the community - why was this patch silently put to a
> "rejected" status?
> Should there no be some kind of explanation?
>
> During this discussion I got the impression that for some reason some members
> of
Hi!
I have a question for the community - why was this patch silently put to a
"rejected" status?
Should there no be some kind of explanation?
During this discussion I got the impression that for some reason some
members of the community
do not want the TOAST functionality, which has such
On Wed, Jun 14, 2023 at 3:47 PM Michael Paquier wrote:
> On Wed, Jun 14, 2023 at 03:38:10PM +0800, Richard Guo wrote:
> > +1. BTW, it seems that GUC_UNIT_TIME is not used anywhere except in
> > GUC_UNIT. I was wondering if we can retire it, but maybe we'd better
> > not. It still indicates
On Tue, Jun 13, 2023 at 3:39 PM Kyotaro Horiguchi
wrote:
> Gurjeet has mentioned that eb.rel cannot be modified by another
> process since the value or memory is in the local stack, and I believe
> he's correct.
>
> If the pointed Relation had been blown out, eb.rel would be left
> dangling, not
On 6/14/23 06:31, Tom Dunstan wrote:
> On Mon, 12 Jun 2023 at 22:37, Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
> Perhaps. So you're proposing to have this as a regular built-in type?
> It's hard for me to judge how popular this feature would be, but I guess
>
Michael Paquier writes:
> On Thu, Jun 01, 2023 at 01:12:22PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> While I was rewriting the regexes I noticed that they were inconsistent
>> about whether they accepted whitespace in the parameter lists, so I took
>> the liberty to make them consistently
On 6/14/23 05:15, Zhijie Hou (Fujitsu) wrote:
> On Tuesday, June 13, 2023 12:19 PM Zhijie Hou (Fujitsu)
> wrote:
>>
>> On Tuesday, June 13, 2023 12:04 PM Amit Kapila
>> wrote:
>>>
>>> On Wed, Jun 7, 2023 at 6:02 PM Tomas Vondra
>>> wrote:
Well, I think the issue is pretty
On Wed, Jun 14, 2023, at 06:31, Tom Dunstan wrote:
> On Mon, 12 Jun 2023 at 22:37, Tomas Vondra
> wrote:
>> Perhaps. So you're proposing to have this as a regular built-in type?
>> It's hard for me to judge how popular this feature would be, but I guess
>> people often use arrays while they
On Wed, Jun 14, 2023 at 03:38:10PM +0800, Richard Guo wrote:
> +1. BTW, it seems that GUC_UNIT_TIME is not used anywhere except in
> GUC_UNIT. I was wondering if we can retire it, but maybe we'd better
> not. It still indicates that we need to use time units table.
Some out-of-core code
On Wed, Jun 14, 2023 at 1:07 PM Masahiko Sawada
wrote:
> On Wed, Jun 14, 2023 at 12:33 PM Japin Li wrote:
> > Hi, hackers
> >
> > We use (GUC_UNIT_MEMORY | GUC_UNIT_TIME) instead of GUC_UNIT even though
> we
> > already define it in guc.h.
> >
> > Maybe using GUC_UNIT is better? Here is a
On 25.05.23 15:20, Tom Lane wrote:
Peter Eisentraut writes:
Until PG15, calling pgindent without arguments would process the whole
tree. Now you get
No files to process at ./src/tools/pgindent/pgindent line 372.
Is that intentional?
It was intentional, cf b16259b3c and the linked
On 06.09.22 07:57, Peter Eisentraut wrote:
I wrote a test for coverage.
Unfortunately, it seems to take quite a while to run the test.
I want to improve these execution times, but I don't know exactly what
to do.
Therefore, I want to hear feedback from many people.
I think having some more
On 6/14/23 09:01, Kyotaro Horiguchi wrote:
At Wed, 14 Jun 2023 08:46:05 +0300, Konstantin Knizhnik
wrote in
But I do not think that it is somehow related with using threads
instead of process.
The question whether to use private or shared cache is not directly
related to threads vs. process
At Wed, 14 Jun 2023 08:46:05 +0300, Konstantin Knizhnik
wrote in
> But I do not think that it is somehow related with using threads
> instead of process.
> The question whether to use private or shared cache is not directly
> related to threads vs. process choice.
Yeah, I unconsciously
On Wed, Jun 14, 2023 at 6:02 AM Tom Lane wrote:
> I wrote:
> > Richard Guo writes:
> >> Oh, wait ... It occurred to me that we may have this same issue with
> >> Memoize cache keys.
>
> > Good catch --- I'll take a closer look tomorrow.
>
> Pushed after a little more fiddling with the comments.
On Mon, Jun 5, 2023 at 10:19 PM Etsuro Fujita wrote:
> To avoid this issue, I am wondering if we should modify
> add_paths_to_joinrel() in back branches so that it just disallows the
> FDW to consider pushing down joins when the restrictlist has
> pseudoconstant clauses. Attached is a patch for
On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote:
> On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote:
> > This being my first commit, I intently looked to check if everything’s
> set
> > up correctly. While it seemed to have hit gitweb and GitHub, it didn’t
> > pgsql-committers
On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote:
> This being my first commit, I intently looked to check if everything’s set
> up correctly. While it seemed to have hit gitweb and GitHub, it didn’t
> pgsql-committers for some reason.
It seems to me that the email of pgsql-committers
On Tue, 13 Jun 2023 at 11:49, Masahiko Sawada wrote:
>
> On Fri, May 26, 2023 at 6:55 PM shveta malik wrote:
> >
> > I have attempted to convert pg_get_indexdef() to use
> > systable_beginscan() based on transaction-snapshot rather than using
> > SearchSysCache(). The latter does not have any
On Tue, Jun 13, 2023 at 12:47 PM Masahiko Sawada
wrote:
>
> On Tue, Jun 6, 2023 at 2:13 PM John Naylor
wrote:
> >
> > I'd need to make sure, but apparently just going from 6 non-empty
memory contexts to 3 (remember all values are embedded here) reduces memory
fragmentation significantly in this
90 matches
Mail list logo
