On Fri, Sep 30, 2022 at 8:40 PM Zhihong Yu wrote:
>
>
> On Fri, Sep 30, 2022 at 3:44 PM Zheng Li wrote:
>
>> Hello,
>>
>> A bloom filter provides early filtering of rows that cannot be joined
>> before they would reach the join operator, the optimization is also
>> called a semi join filter
Hi,
I created a postgers_fdw server lookback as the test does. Then run the
following SQLs
create table t1(c0 int);
insert into t1 values(1);
create foreign table ft1(
c0 int
) SERVER loopback OPTIONS (schema_name 'public', table_name 't1');
Then started a transaction that runs queries on
On Fri, Sep 30, 2022 at 3:44 PM Zheng Li wrote:
> Hello,
>
> A bloom filter provides early filtering of rows that cannot be joined
> before they would reach the join operator, the optimization is also
> called a semi join filter (SJF) pushdown. Such a filter can be created
> when one child of
Hi,
On 2022-09-30 21:19:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I see two potential ways of dealing with this reliably on windows: - error
> > out
> > if a prefix is not drive-local, that's easy enough to check, something like:
> > normalized_prefix.startswith('/') and not
On Fri, Sep 30, 2022 at 5:20 PM Andres Freund wrote:
> I think it'd be an OK tradeoff to optimize WAL usage for a few of the worst to
> pay off for 56bit relfilenodes. The class of problems foreclosed is large
> enough to "waste" "improvement potential" on this.
I agree overall.
A closely
On Fri, Sep 30, 2022 at 4:23 AM Bruce Momjian wrote:
>
> I don't think this patch is going in the right direction, and I think we
> need to step back to see why.
Thanks a lot Bruce for providing insights.
> First, let's see how synchronous replication works. Each backend waits
> for one or
Andres Freund writes:
> I see two potential ways of dealing with this reliably on windows: - error out
> if a prefix is not drive-local, that's easy enough to check, something like:
> normalized_prefix.startswith('/') and not normalized_prefix.startswith('//')
> as the installation on windows is
Hi,
On 2022-09-30 10:17:37 -0700, Andres Freund wrote:
> Agreed - I was just trying to give background. I'm inclined to just go for
> Junwang Zhao's patch for now.
That turns out to break tests on windows right now - but it's not the fault of
the patch. Paths on windows are just evil:
We do the
Hi,
On 2022-09-30 15:36:11 +0530, Dilip Kumar wrote:
> I have done some testing around this area to see the impact on WAL
> size especially when WAL sizes are smaller, with a very simple test
> with insert/update/delete I can see around an 11% increase in WAL size
> [1] then I did some more test
On Fri, Sep 30, 2022 at 07:05:38PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
>>> ... and now requires double alignment ... did you fix its typalign?
>
>> Nope, I missed that, thanks for pointing it out. Should we move ai_privs
On Tue, Sep 27, 2022 at 11:20 AM Melanie Plageman
wrote:
> v30 attached
> rebased and pgstat_io_ops.c builds with meson now
> also, I tested with pgstat_report_stat() only flushing when forced and
> tests still pass
>
First of all, I'm excited about this patch, and I think it will be a big
help
On Fri, Sep 30, 2022 at 3:30 PM Jehan-Guillaume de Rorthais
wrote:
> Hi,
>
> Please, find in attachment a small serie of patch:
>
> 0001 fix the constraint parenting bug. Not much to say. It's basically
> your
> patch we discussed with some more comments and the check on contype
> equals to
Nathan Bossart writes:
> On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
>> ... and now requires double alignment ... did you fix its typalign?
> Nope, I missed that, thanks for pointing it out. Should we move ai_privs
> to the beginning of the struct, too?
Don't see any point, there
Hi,
On 2022-09-30 23:51:04 +0200, Peter Eisentraut wrote:
> On 27.09.22 03:19, Andres Freund wrote:
> > Attaches is version 17. Other changes:
> [23 attachments]
>
> How shall we proceed here? The more progress we make, the more patches
> appear. ;-)
> Maybe close this commitfest entry now, and
On Fri, Sep 30, 2022 at 06:00:53PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> The main one I see is AclItem, which increases from 12 bytes to 16 bytes.
>
> ... and now requires double alignment ... did you fix its typalign?
Nope, I missed that, thanks for pointing it out. Should we
Hi,
Please, find in attachment a small serie of patch:
0001 fix the constraint parenting bug. Not much to say. It's basically your
patch we discussed with some more comments and the check on contype equals to
either primary, unique or exclusion.
0002 fix the self-FK being cloned twice
> Sure, but the model isn't the problem here, really -- not to me. The
> problem is that the planner can in some cases choose a plan that is
> inherently unreasonable, at least in practical terms. You're talking
> about uncertainties. But I'm actually talking about the opposite thing
> --
Nathan Bossart writes:
> The main one I see is AclItem, which increases from 12 bytes to 16 bytes.
... and now requires double alignment ... did you fix its typalign?
We could conceivably dodge the alignment increase by splitting the 64-bit
field into two 32-bit fields, one for base privileges
On 27.09.22 03:19, Andres Freund wrote:
Attaches is version 17. Other changes:
[23 attachments]
How shall we proceed here? The more progress we make, the more patches
appear. ;-)
Maybe close this commitfest entry now, and start new threads for each
subsequent topic.
On Fri, Sep 30, 2022 at 04:15:24PM -0400, Tom Lane wrote:
> In view of the recent mess around bigint relfilenodes, it seems to me
> that we shouldn't move forward with widening AclMode unless somebody
> runs down which structs will get wider (or more aligned) and how much
> that'll cost us. Maybe
Hi Etsuro,
The patch needs rebase due to commits 4036bcbbb, 8c8d307f8 and
82699edbf, so I updated the patch. Attached is a new version, in
which I also tweaked comments a little bit.
After rebase the file `postgres_fdw.out` and applied to master branch,
make and make check are all ok for
On Fri, Sep 30, 2022 at 7:47 AM Andrey Chudnovsky
wrote:
> > How should we communicate those pieces to a custom client when it's
> > passing a token directly? The easiest way I can see is for the custom
> > client to speak the OAUTHBEARER protocol directly (e.g. SASL plugin).
> > If you had to
On Fri, Sep 30, 2022 at 05:04:43PM +1300, Thomas Munro wrote:
> Please go ahead! One thing I had in my notes to check with this patch
> is whether there might be a bug due to computing all times in
> microseconds, but sleeping for a number of milliseconds without
> rounding up (what I mean is
On Wed, Aug 31, 2022 at 8:56 AM Robert Haas wrote:
> In order to apply this patch, we'd need to reach a conclusion about
> the matters mentioned in
> http://postgr.es/m/ca+tgmobheyynw9vrhvolvd8odspbjuu9cbk6tms6owd70hf...@mail.gmail.com
> -- and thinking about this patch might shed some light on
Nathan Bossart writes:
> Are there any remaining concerns about this approach? I'm happy to do any
> testing that folks deem necessary, or anything else really that might help
> move this patch set forward. If we don't want to extend AclMode right
> away, we could also keep it in our back
I wrote:
> Given the previous complaints about db0d67db2, I wonder if it's not
> most prudent to revert it. I doubt we are going to get satisfactory
> behavior out of it until there's fairly substantial improvements in
> all these underlying estimates.
After spending some more time looking at
On Wed, Sep 28, 2022 at 01:12:22PM -0700, Nathan Bossart wrote:
> On Wed, Sep 28, 2022 at 03:09:46PM -0400, Stephen Frost wrote:
>> The max is the same regardless of the size..? Considering the size is
>> capped since pg_class doesn’t (and isn’t likely to..) have a toast table,
>> that seems
Hi,
This issue does occasionally happen in CI, as e.g. noted in this thread:
https://www.postgresql.org/message-id/20220930185345.GD6256%40telsasoft.com
On 2022-08-18 15:17:47 +0530, Amit Kapila wrote:
> I agree with you that getting rid of the clean-up lock on the new
> bucket is a more
On Thu, Sep 29, 2022 at 11:44 PM Benjamin Coutu wrote:
> I think these things are orthogonal.
I agree that they're orthogonal. I just meant that execution time
strategies seem underexplored in general.
> No matter how good the cost model ever gets, we will always have degenerate
> cases.
Hi,
On 2022-09-30 13:53:45 -0500, Justin Pryzby wrote:
> On Wed, Aug 17, 2022 at 07:51:34AM +1200, Thomas Munro wrote:
> > Here's a draft patch that adds a minimal sigaction() implementation
> > for Windows. It doesn't implement stuff we're not using, for sample
> > sa_sigaction functions, but
On Wed, Aug 17, 2022 at 07:51:34AM +1200, Thomas Munro wrote:
> Here's a draft patch that adds a minimal sigaction() implementation
> for Windows. It doesn't implement stuff we're not using, for sample
> sa_sigaction functions, but it has the sa_mask feature so we can
> harmonize the stuff that I
On Thu, Sep 29, 2022 at 9:00 PM David Rowley wrote:
> I understand that what you propose would be a fast way to fix this
> issue. However, if we went and changed the join path creation code to
> not add non-parameterised nested loop paths when other paths exist,
> then how could we ever dare to
On Fri, Sep 30, 2022 at 10:43 AM Robert Haas wrote:
> But it's unnecessary to do this computation at runtime for every separate
> unparameterized nested loop: we can do it right here, in a generic
> way, for every such loop.
It's not just that the risks are ludicrously high, of course. The
Hi,
On 2022-09-30 17:58:31 +0200, Vik Fearing wrote:
> On 9/7/22 12:03, Dave Page wrote:
> > Here's a v4 patch. This reverts to using
> > GetCurrentTransactionStopTimestamp() for the last_scan times, and will
> > set xactStopTimestamp the first time GetCurrentTransactionStopTimestamp()
> > is
Hi,
On 9/30/22 2:00 AM, Michael Paquier wrote:
On Wed, Sep 28, 2022 at 04:24:44PM +0900, Michael Paquier wrote:
Hmm, indeed. It would be more reliable to rely on the contents
returned by getpeereid()/getpwuid() after one successful peer
connection, then use it in the map. I was wondering
On Thu, Sep 29, 2022 at 7:46 PM Tom Lane wrote:
> Agreed, but dealing with uncertainty in those numbers is an enormous
> task if you want to do it right. "Doing it right", IMV, would start
> out by extending all the selectivity estimation functions to include
> error bars; then we could have
Hi,
On 2022-09-30 13:13:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-09-30 08:59:53 -0700, Andres Freund wrote:
> >> On 2022-09-30 11:45:35 -0400, Tom Lane wrote:
> >>> Can we have a platform-dependent default?
>
> >> Not easily in that spot, I think.
>
> > For background: The
Andres Freund writes:
> On 2022-09-30 08:59:53 -0700, Andres Freund wrote:
>> On 2022-09-30 11:45:35 -0400, Tom Lane wrote:
>>> Can we have a platform-dependent default?
>> Not easily in that spot, I think.
> For background: The reason for that is that meson doesn't yet know what the
>
Hi,
On 2022-09-30 08:59:53 -0700, Andres Freund wrote:
> On 2022-09-30 11:45:35 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > One concern with that is that default would also apply to windows -
> > > autoconf
> > > didn't have to care about that. I just tried it, and it "just" ends up
I wrote:
> The most likely theory, I think, is that that compiler is generating
> slightly different floating-point code causing different plans to
> be costed slightly differently than what the test case is expecting.
> Probably, the different orderings of the keys in this test case have
>
Hi,
On 2022-09-30 12:13:11 -0400, Tom Lane wrote:
> "kuroda.hay...@fujitsu.com" writes:
> > Hmm, I was not sure about additional conditions, sorry.
> > I could reproduce with followings steps:
>
> I tried this on a 32-bit VM with gcc 11.3, but couldn't reproduce.
> You said earlier
>
> >> OS:
"kuroda.hay...@fujitsu.com" writes:
> Hmm, I was not sure about additional conditions, sorry.
> I could reproduce with followings steps:
I tried this on a 32-bit VM with gcc 11.3, but couldn't reproduce.
You said earlier
>> OS: RHEL 6.10 server
>> Arch: i686
>> Gcc: 4.4.7
That is an awfully
Hi,
On 2022-09-30 11:45:35 -0400, Tom Lane wrote:
> Andres Freund writes:
> > One concern with that is that default would also apply to windows - autoconf
> > didn't have to care about that. I just tried it, and it "just" ends up
> > installing it into c:/usr/local/pgsql (assuming the build dir
On 9/7/22 12:03, Dave Page wrote:
Here's a v4 patch. This reverts to using
GetCurrentTransactionStopTimestamp() for the last_scan times, and will
set xactStopTimestamp the first time GetCurrentTransactionStopTimestamp()
is called, thus avoiding multiple gettimeofday() calls.
On Wed, Sep 28, 2022 at 3:18 PM John Naylor
wrote:
>
> On Wed, Sep 28, 2022 at 10:49 AM Masahiko Sawada
> wrote:
>
> > BTW We need to consider not only aset/slab but also DSA since we
> > allocate dead tuple TIDs on DSM in parallel vacuum cases. FYI DSA uses
> > the following size classes:
> >
Andres Freund writes:
> On 2022-09-30 23:21:22 +0800, Junwang Zhao wrote:
>> autoconf set PREFIX to /usr/local/pgsql, so I think we should
>> do the same in meson build.
> That makes sense.
+1
> One concern with that is that default would also apply to windows - autoconf
> didn't have to care
Hi,
On 2022-09-30 23:21:22 +0800, Junwang Zhao wrote:
> autoconf set PREFIX to /usr/local/pgsql, so I think we should
> do the same in meson build.
That makes sense.
One concern with that is that default would also apply to windows - autoconf
didn't have to care about that. I just tried it, and
Hi Richard,
Sorry for not responding for a long time, I missed the previous email
by accident :-)
I attached a newer patch based on your suggestions and created an
entry in cf manager.
https://commitfest.postgresql.org/40/3924/
Best Regards,
Xing Guo
On 9/16/22, Richard Guo wrote:
> On Wed,
autoconf set PREFIX to /usr/local/pgsql, so I think we should
do the same in meson build.
This will group all the targets generated by postgres in the same directory.
--
Regards
Junwang Zhao
0001-meson-add-a-default-option-prefix-usr-local-pgsql.patch
Description: Binary data
> The most concrete example I can see is with the OAUTHBEARER error
> response. If you want to eventually handle differing scopes per role,
> or different error statuses (which the proof-of-concept currently
> hardcodes as `invalid_token`), then the client can't assume it knows
> what the server
On Fri, 30 Sep 2022 at 22:09, Bharath Rupireddy
wrote:
> On Fri, Sep 30, 2022 at 7:30 PM Japin Li wrote:
>>
>> When I try to use -Wunused-parameter, I find there are many warnings :-( .
>
> Great!
>
> I think we can't just remove every unused parameter, for instance, it
> makes sense to
On Fri, Sep 30, 2022 at 7:30 PM Japin Li wrote:
>
> When I try to use -Wunused-parameter, I find there are many warnings :-( .
Great!
I think we can't just remove every unused parameter, for instance, it
makes sense to retain PlannerInfo *root parameter even though it's not
used now, in future
On Fri, 30 Sep 2022 at 19:32, Bharath Rupireddy
wrote:
> On Fri, Sep 30, 2022 at 1:07 PM Drouvot, Bertrand
> wrote:
>>
>> Hi,
>>
>> While resuming the work on [1] I noticed that:
>>
>> - there is an unused parameter in log_heap_visible()
>> - the comment associated to the function is not in
On Tue, Sep 20, 2022 at 6:43 PM Robert Haas wrote:
> On Tue, Sep 20, 2022 at 5:00 AM Himanshu Upadhyaya
> wrote:
> > Please find it attached.
>
> This patch still has no test cases. Just as we have test cases for the
> existing corruption checks, we should have test cases for these new
>
Hi,
On 9/30/22 1:32 PM, Bharath Rupireddy wrote:
On Fri, Sep 30, 2022 at 1:07 PM Drouvot, Bertrand
wrote:
Hi,
While resuming the work on [1] I noticed that:
- there is an unused parameter in log_heap_visible()
- the comment associated to the function is not in "sync" with the
current
Hi,
On 7/6/22 3:30 PM, Drouvot, Bertrand wrote:
Hi,
On 10/28/21 11:07 PM, Andres Freund wrote:
Hi,
On 2021-10-28 16:24:22 -0400, Robert Haas wrote:
On Wed, Oct 27, 2021 at 2:56 AM Drouvot, Bertrand
wrote:
So you have in mind to check for XLogLogicalInfoActive() first, and
if true, then
On Fri, Sep 30, 2022 at 1:07 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> While resuming the work on [1] I noticed that:
>
> - there is an unused parameter in log_heap_visible()
> - the comment associated to the function is not in "sync" with the
> current implementation (referring a "block" that is
Thanks! I pushed 0001.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
Hi,
On Sep 8, 2022, 19:08 +0800, Matthias van de Meent
, wrote:
>
> PFA a patch that rectifies this issue, by moving the XLogBeginInsert()
> down to where 1.) we have all relevant buffers pinned and locked, and
> 2.) we're in a critical section, making that part of the code
> consistent with the
On Thu, Sep 29, 2022 at 2:36 AM Robert Haas wrote:
> 2. WAL Size. Block references in the WAL are by RelFileLocator, so if
> you make RelFileLocators bigger, WAL gets bigger. We'd have to test
> the exact impact of this, but it seems a bit scary
I have done some testing around this area to see
HI,
On Sep 8, 2022, 19:08 +0800, Matthias van de Meent
, wrote:
> In general, this works fine, except that in ginHeapTupleFastInsert we
> call XLogBeginInsert() before the last of the buffers for the eventual
> record was read, thus creating a path where eviction is possible in a
>
It seems like the issue discussed in [0] is back, but this time for XSL imports
via xsltproc. The http link now redirects with a 301 (since when I don't know,
but it worked recently):
$ curl -I http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
HTTP/1.1 301 Moved Permanently
On 2022-Sep-30, Michael Paquier wrote:
> On Thu, Sep 29, 2022 at 09:07:34PM -0700, Andres Freund wrote:
> > ISTM we should at least install a SIGINT/TERM handler in Cluster.pm that
> > does
> > the stuff we already do in END.
>
> Hmm, indeed. And here I thought that END was actually taking
Here are my review comments for the v35-0001 patch:
==
1. Commit message
Currently, for large transactions, the publisher sends the data in multiple
streams (changes divided into chunks depending upon logical_decoding_work_mem),
and then on the subscriber-side, the apply worker writes the
> Actually, if we wanted to improve things in this area, we should have a
> set of queries that don't chose optimal plans we can test with. We used
> to see them a lot before we had extended statistics, but I don't
> remember seeing many recently, let alone a collection of them. I guess
> that
2022-09-21 11:45 に Fujii Masao wrote:
We can execute the shell commands via psql in various ways
other than \! meta-command. For example,
* `command`
* \g | command
* \gx | command
* \o | command
* \w | command
* \copy ... program 'command'
ON_ERROR_STOP should handle not only \! but also all
Hi,
While resuming the work on [1] I noticed that:
- there is an unused parameter in log_heap_visible()
- the comment associated to the function is not in "sync" with the
current implementation (referring a "block" that is not involved anymore)
Attached a tiny patch as an attempt to address
> Agreed, but dealing with uncertainty in those numbers is an enormous
> task if you want to do it right. "Doing it right", IMV, would start
> out by extending all the selectivity estimation functions to include
> error bars; then we could have error bars on rowcount estimates and
> then costs;
On Thu, Sep 29, 2022 at 10:35:20AM -0700, Nathan Bossart wrote:
> I've marked this one as ready-for-committer.
UnpinBuffer() is local to bufmgr.c, so it would not be an issue for
external code, and that's 10 callers that don't need to worry about
that anymore. 2d115e4 is from 2015, and nobody
> In general I suspect that we'd be better off focussing on mitigating
> the impact at execution time. There are at least a few things that we
> could do there, at least in theory. Mostly very ambitious, long term
> things.
I think these things are orthogonal. No matter how good the cost model
On Thu, Sep 29, 2022 at 09:07:34PM -0700, Andres Freund wrote:
> ISTM we should at least install a SIGINT/TERM handler in Cluster.pm that does
> the stuff we already do in END.
Hmm, indeed. And here I thought that END was actually taking care of
that on an interrupt..
--
Michael
signature.asc
> Right. But that seems fraught with difficulty. I suspect that the
> costs that the planner attributes to each plan often aren't very
> reliable in any absolute sense, even when everything is working very
> well by every available metric. Even a very noisy cost model with
> somewhat inaccurate
Hi all,
I have bumped a few days ago on the fact that COERCE_SQL_SYNTAX
(introduced by 40c24bf) and SQLValueFunction are around to do the
exact same thing, as known as enforcing single-function calls with
dedicated SQL keywords. For example, keywords like SESSION_USER,
CURRENT_DATE, etc. go
73 matches
Mail list logo
