On Fri, Jul 24, 2020 at 7:36 PM Tom Lane wrote:
>
> Robert Haas writes:
> > Well, I think the comments could be more clear - for the insert case
> > specifically - about which cases you think are and are not safe.
>
Okay, I'll update the patch accordingly.
> Yeah, the proposed comment changes d
so 25. 7. 2020 v 0:34 odesílatel Tom Lane napsal:
> [ redirecting to -hackers ]
>
> I wrote:
> > The core issue here is "how do we know whether the table is likely to
> stay
> > empty?". I can think of a couple of more or less klugy solutions:
>
For these special cases is probably possible to e
On Fri, Jul 24, 2020 at 1:35 PM Wang, Shenhao
wrote:
>
> Hi, hackers
>
> The source looks like:
>
> case ECPGt_bytea:
> {
> struct ECPGgeneric_varchar *variable =
> (struct ECPGgeneric_varchar *) (var->value);
>
> ..
> }
>
On Fri, Jul 24, 2020 at 12:41 PM Bharath Rupireddy
wrote:
>
> On Thu, Jul 23, 2020 at 12:54 PM vignesh C wrote:
> >
> > Thanks for reviewing and adding your thoughts, My comments are inline.
> >
> > On Fri, Jul 17, 2020 at 1:21 PM Bharath Rupireddy
> > wrote:
> > >
> > > The same hang issue can
On Thu, Jul 16, 2020 at 7:35 PM Georgios wrote:
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, July 11, 2020 3:16 PM, vignesh C wrote:
>
> > On Mon, Jul 6, 2020 at 1:24 PM Georgios gkokola...@protonmail.com wrote:
> >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Monday, July 6, 2020 3
On Sat, 25 Jul 2020 at 10:34, Tom Lane wrote:
> I wrote:
> > 1. Arrange to send out a relcache inval when adding the first page to
> > a table, and then remove the planner hack for disbelieving relpages = 0.
> > I fear this'd be a mess from a system structural standpoint, but it might
> > work fai
On 2020-07-24 18:15:15 -0300, Ranier Vilela wrote:
> Em sex., 24 de jul. de 2020 às 14:16, Andres Freund
> escreveu:
>
> > On 2020-07-24 14:05:04 -0300, Ranier Vilela wrote:
> > > Latest Postgres
> > > Windows 64 bits
> > > msvc 2019 64 bits
> > >
> > > Patches applied v12-0001 to v12-0007:
> > >
Hi,
On 2020-06-12 14:37:15 -0700, Andres Freund wrote:
> On 2020-06-11 11:14:02 -0700, Jeff Davis wrote:
> > On Thu, 2020-06-11 at 10:45 -0700, Andres Freund wrote:
> > > Did you run any performance tests?
> >
> > Yes, I reproduced your ~12% regression from V12, and this patch nearly
> > eliminate
[ redirecting to -hackers ]
I wrote:
> The core issue here is "how do we know whether the table is likely to stay
> empty?". I can think of a couple of more or less klugy solutions:
> 1. Arrange to send out a relcache inval when adding the first page to
> a table, and then remove the planner hac
Em sex., 24 de jul. de 2020 às 14:16, Andres Freund
escreveu:
> On 2020-07-24 14:05:04 -0300, Ranier Vilela wrote:
> > Latest Postgres
> > Windows 64 bits
> > msvc 2019 64 bits
> >
> > Patches applied v12-0001 to v12-0007:
> >
> > C:\dll\postgres\contrib\pgstattuple\pgstatapprox.c(74,28): warnin
On Fri, Jul 24, 2020 at 12:16 PM Tomas Vondra
wrote:
> Maybe, but we're nowhere close to these limits. See this table which I
> posted earlier:
>
>2MB Planned Partitions: 64HashAgg Batches: 4160
>4MB Planned Partitions: 128HashAgg Batches: 16512
>8MB
Pavel Borisov writes:
> ср, 22 июл. 2020 г. в 19:10, Tom Lane :
>> The other issue we have to agree on is whether we want to sneak this
>> fix into v13, or wait another year for it. I feel like it's pretty
>> late to be making potentially API-breaking changes, but on the other
>> hand this is und
On Fri, Jul 24, 2020 at 11:03:54AM -0700, Peter Geoghegan wrote:
On Fri, Jul 24, 2020 at 8:19 AM Robert Haas wrote:
This is all really good analysis, I think, but this seems like the key
finding. It seems like we don't really understand what's actually
getting written. Whether we use hash or so
On Fri, Jul 24, 2020 at 7:34 AM Robert Haas wrote:
>
> On Thu, Jul 23, 2020 at 12:11 PM Soumyadeep Chakraborty
> wrote:
> > In the read-only level I was suggesting, I wasn't suggesting that we
> > stop WAL flushes, in fact we should flush the WAL before we mark the
> > system as read-only. Once
On Fri, Jul 24, 2020 at 7:32 AM Robert Haas wrote:
>
> On Wed, Jul 22, 2020 at 6:03 PM Soumyadeep Chakraborty
> wrote:
> > So if we are not going to address those cases, we should change the
> > syntax and remove the notion of read-only. It could be:
> >
> > ALTER SYSTEM SET wal_writes TO off|on;
pá 24. 7. 2020 v 19:46 odesílatel Tom Lane napsal:
> Andres Freund writes:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that?
>
> The more I think about that the
On Fri, Jul 24, 2020 at 1:40 AM Tomas Vondra
wrote:
> Maybe, not sure what exactly you think is pathological? The trouble is
> hashagg has to spill input tuples but the memory used in no-spill case
> represents aggregated groups, so I'm not sure how you could extrapolate
> from that ...
Yeah, but
I tried to duplicate a multiple-second ts_headline call here, and
failed to, so there must be something I'm missing. Can you provide
a concrete example? I'd like to do some analysis with perf.
regards, tom lane
On Fri, Jul 24, 2020 at 8:19 AM Robert Haas wrote:
> This is all really good analysis, I think, but this seems like the key
> finding. It seems like we don't really understand what's actually
> getting written. Whether we use hash or sort doesn't seem like it
> should have this kind of impact on h
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Hm. I'd vote for a CFI within the recursion in TS_execute(), if there's
>> not one there yet. Maybe hlFirstIndex needs one too --- if there are
>> a lot of words in the query, maybe that could be slow? Did you pin the
>> blame do
Hi hackers,
We discussed in another email thread[1], that it will be helpful if we can
display offset along with block number in vacuum error. Here, proposing a
patch to add offset along with block number in vacuum errors.
In commit b61d161(Introduce vacuum errcontext to display additional
informa
Andres Freund writes:
> Wouldn't the rule that I proposed earlier, namely that sub-expressions
> that involve only "proper" constants continue to get evaluated even
> within CASE, largely address that?
The more I think about that the less I like it. It'd make the behavior
even harder to reason a
On July 24, 2020 10:30:37 AM PDT, Pavel Stehule wrote:
>pá 24. 7. 2020 v 19:13 odesílatel Andres Freund
>napsal:
>> Your earlier example of a WHEN ... THEN upper('constant') ... would
>> still have the upper('constant') be evaluated, because it doesn't
>> involve a parameter. And e.g. THEN upp
pá 24. 7. 2020 v 19:13 odesílatel Andres Freund napsal:
> Hi,
>
> On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> > pá 24. 7. 2020 v 18:49 odesílatel Andres Freund
> napsal:
> > > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > > that involve only "proper" constan
Hi,
On 2020-07-23 22:34:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm a bit worried about a case like:
>
> > CREATE FUNCTION yell(int, int)
> > RETURNS int
> > IMMUTABLE
> > LANGUAGE SQL AS $$
> >SELECT CASE WHEN $1 != 0 THEN 17 / $2 ELSE NULL END
> > $$;
>
> > EXPLAIN SELECT ye
Robert Haas writes:
> Like Pavel, and I think implicitly Dagfinn and Andres, I'm not sure I
> believe this. Pavel's example is a good one. The leakproof exception
> helps, but it doesn't cover everything. Users I've encountered throw
> things like date_trunc() and lpad() into SQL code and expect t
On 2020-07-24 14:05:04 -0300, Ranier Vilela wrote:
> Latest Postgres
> Windows 64 bits
> msvc 2019 64 bits
>
> Patches applied v12-0001 to v12-0007:
>
> C:\dll\postgres\contrib\pgstattuple\pgstatapprox.c(74,28): warning C4013:
> 'GetOldestXmin' indefinido; assumindo extern retornando int
> [C:\d
Hi,
On 2020-07-24 19:03:30 +0200, Pavel Stehule wrote:
> pá 24. 7. 2020 v 18:49 odesílatel Andres Freund napsal:
> > Wouldn't the rule that I proposed earlier, namely that sub-expressions
> > that involve only "proper" constants continue to get evaluated even
> > within CASE, largely address that
On Thu, Jul 23, 2020 at 10:14 PM Amul Sul wrote:
>
> On Fri, Jul 24, 2020 at 6:28 AM Soumyadeep Chakraborty
> wrote:
> > In case it is necessary, the patch set does not wait for the checkpoint to
> > complete before marking the system as read-write. Refer:
> >
> > /* Set final state by clearing
Latest Postgres
Windows 64 bits
msvc 2019 64 bits
Patches applied v12-0001 to v12-0007:
C:\dll\postgres\contrib\pgstattuple\pgstatapprox.c(74,28): warning C4013:
'GetOldestXmin' indefinido; assumindo extern retornando int
[C:\dll\postgres
C:\dll\postgres\contrib\pg_visibility\pg_visibility.c(569
pá 24. 7. 2020 v 18:49 odesílatel Andres Freund napsal:
> Hi,
>
> On 2020-07-24 12:31:05 -0400, Robert Haas wrote:
> > On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> > > Every so often we get a complaint like [1] about how a CASE should have
> > > prevented a run-time error and didn't, becau
Hi,
On 2020-07-24 11:06:58 -0400, Robert Haas wrote:
> On Thu, Jul 23, 2020 at 2:10 PM Andres Freund wrote:
> > In the case the HOT logic triggers, we'll call
> > heap_prepare_freeze_tuple() even when the tuple is dead.
>
> I think this is very bad. I've always been confused about these
> comment
Hi,
On 2020-07-24 12:31:05 -0400, Robert Haas wrote:
> On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> > Every so often we get a complaint like [1] about how a CASE should have
> > prevented a run-time error and didn't, because constant-folding tried
> > to evaluate a subexpression that would
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm looking into an issue that we're seeing on the PG archives server
> > with runaway queries that don't seem to ever want to end- and ignore
> > signals.
>
> > This is PG11, 11.8-1.pgdg100+1 specifically on Debian/bu
On Fri, Jul 24, 2020 at 12:17 PM Tom Lane wrote:
> I went through the system's built-in implicit coercions to see
> which ones are unconditionally successful. These could all be
> marked leakproof, as per attached patch. This came up in the
> context of the nearby discussion about CASE, but it s
On Thu, Jul 23, 2020 at 12:57 PM Tom Lane wrote:
> Every so often we get a complaint like [1] about how a CASE should have
> prevented a run-time error and didn't, because constant-folding tried
> to evaluate a subexpression that would not have been entered at run-time.
Yes, I've heard such compl
Stephen Frost writes:
> I'm looking into an issue that we're seeing on the PG archives server
> with runaway queries that don't seem to ever want to end- and ignore
> signals.
> This is PG11, 11.8-1.pgdg100+1 specifically on Debian/buster and what
> we're seeing is the loop in hlCover() (wparser_
I went through the system's built-in implicit coercions to see
which ones are unconditionally successful. These could all be
marked leakproof, as per attached patch. This came up in the
context of the nearby discussion about CASE, but it seems like
an independent improvement. If you have a funct
Hi,
On 2020-07-24 11:33:52 -0400, Dave Cramer wrote:
> For logical replication there is no need to implement this, but others are
> using the pgoutput plugin for Change Data Capture. The reason they are
> using pgoutput is because it is guaranteed to be available as it is in core
> postgres.
>
>
Greetings,
I'm looking into an issue that we're seeing on the PG archives server
with runaway queries that don't seem to ever want to end- and ignore
signals.
This is PG11, 11.8-1.pgdg100+1 specifically on Debian/buster and what
we're seeing is the loop in hlCover() (wparser_def.c:2071 to 2093) i
On Fri, Jul 24, 2020 at 11:18:48AM -0400, Robert Haas wrote:
On Thu, Jul 23, 2020 at 9:22 PM Tomas Vondra
wrote:
2MB 4MB8MB64MB256MB
---
hash 6.716.70 6.736.44
On Mon, Jun 29, 2020 at 12:31 PM Andres Freund wrote:
> > This "custom compression methods" thread - vintage 2017 - Original
> > code by Nikita Glukhov, later work by Ildus Kurbangaliev
> > The "pluggable compression support" thread - vintage 2013 - Andres Freund
> > The "plgz performance" thread
For logical replication there is no need to implement this, but others are
using the pgoutput plugin for Change Data Capture. The reason they are
using pgoutput is because it is guaranteed to be available as it is in core
postgres.
Implementing LogicalDecodeMessageCB provides some synchronization
I wrote:
> Ah, I see what you mean. Yeah, that throws an error today, and it
> still would with the patch I was envisioning (attached), because
> inlining does Param substitution in a different way. I'm not
> sure that we could realistically fix the inlining case with this
> sort of approach.
He
On Thu, Jul 23, 2020 at 9:22 PM Tomas Vondra
wrote:
>2MB 4MB8MB64MB256MB
> ---
> hash 6.716.70 6.736.44 5.81
> hash CP_SMALL_TLIST 5.285.26 5.24
On Thu, Jul 23, 2020 at 2:10 PM Andres Freund wrote:
> In the case the HOT logic triggers, we'll call
> heap_prepare_freeze_tuple() even when the tuple is dead.
I think this is very bad. I've always been confused about these
comments, but I couldn't quite put my finger on the problem. Now I
think
Hi Tom,
sorry for the delay,
I experimented with adding a number-of-evaluations parameter to
cost_qual_eval, and found that the majority of call sites do have
something realistic they can pass. The attached very-much-WIP
patch shows my results so far. There's a lot of loose ends:
I like the i
Hi Melanie,
Sorry for the delay.
I've just started looking at this patch today, but I was wondering if
you might include a test case which minimally reproduces the original
problem you had.
I could reproduce it with an easier generated data set, please see attached.
However, to be honest with
On Fri, Jul 24, 2020 at 7:10 AM Bharath Rupireddy
wrote:
> I looked at what actually llvm_shutdown() does? It frees up JIT stacks, also
> if exists perf related resource, using LLVMOrcDisposeInstance() and
> LLVMOrcUnregisterPerf(), that were dynamically allocated in
> llvm_session_initialize t
On Thu, Jul 23, 2020 at 10:04 PM Andres Freund wrote:
> I think we should consider introducing XACTFATAL or such, guaranteeing
> the transaction gets aborted, without requiring a FATAL. This has been
> needed for enough cases that it's worthwhile.
Seems like that would need a separate discussion,
On Thu, Jul 23, 2020 at 12:11 PM Soumyadeep Chakraborty
wrote:
> In the read-only level I was suggesting, I wasn't suggesting that we
> stop WAL flushes, in fact we should flush the WAL before we mark the
> system as read-only. Once the system declares itself as read-only, it
> will not perform an
On Wed, Jul 22, 2020 at 6:03 PM Soumyadeep Chakraborty
wrote:
> So if we are not going to address those cases, we should change the
> syntax and remove the notion of read-only. It could be:
>
> ALTER SYSTEM SET wal_writes TO off|on;
> or
> ALTER SYSTEM SET prohibit_wal TO off|on;
This doesn't rea
On Fri, Jul 24, 2020 at 4:35 AM Tom Lane wrote:
> Andres Freund writes:
> > I'm a bit worried about a case like:
>
> > CREATE FUNCTION yell(int, int)
> > RETURNS int
> > IMMUTABLE
> > LANGUAGE SQL AS $$
> >SELECT CASE WHEN $1 != 0 THEN 17 / $2 ELSE NULL END
> > $$;
>
> > EXPLAIN SELECT yell(
Robert Haas writes:
> Well, I think the comments could be more clear - for the insert case
> specifically - about which cases you think are and are not safe.
Yeah, the proposed comment changes don't actually add much. Also
please try to avoid inserting non-ASCII into the source code;
at least
On Fri, Jul 24, 2020 at 7:59 AM Amit Kapila wrote:
> On Fri, Jul 17, 2020 at 11:24 AM Amit Kapila wrote:
> > Do you have something else in mind?
>
> I am planning to commit the comments change patch attached in the
> above email [1] next week sometime (probably Monday or Tuesday) unless
> you hav
Peter Eisentraut writes:
> On 2020-07-17 10:46, Peter Eisentraut wrote:
>> v1-0001-Rename-configure.in-to-configure.ac.patch
> I have committed that, and I have sent feedback to the Autoconf
> developers about our concerns about the slowness of some of the new tests.
Sounds good. Do we want to
On Fri, Jul 24, 2020 at 10:40:47AM +0200, Tomas Vondra wrote:
On Thu, Jul 23, 2020 at 07:33:45PM -0700, Peter Geoghegan wrote:
On Thu, Jul 23, 2020 at 6:22 PM Tomas Vondra
wrote:
So let me share some fresh I/O statistics collected on the current code
using iosnoop. I've done the tests on two d
On Fri, Jul 24, 2020 at 7:34 AM Andres Freund wrote:
>
> Hi,
Thanks for looking at the patch.
>
> > From f0188a48723b1ae7372bcc6a344ed7868fdc40fb Mon Sep 17 00:00:00 2001
> > From: Amul Sul
> > Date: Fri, 27 Mar 2020 05:05:38 -0400
> > Subject: [PATCH v3 2/6] Add alter system read only/write sy
On Fri, Jul 17, 2020 at 11:24 AM Amit Kapila wrote:
>
> Do you have something else in mind?
>
I am planning to commit the comments change patch attached in the
above email [1] next week sometime (probably Monday or Tuesday) unless
you have something more to add?
[1] -
https://www.postgresql.or
On Tue, Jul 21, 2020 at 1:17 AM Robert Haas wrote:
>
> On Tue, Jul 7, 2020 at 12:55 PM Andres Freund wrote:
> > What are you proposing? For now we could easily enough work around this
> > by just making it a on_proc_exit() callback, but that doesn't really
> > change the fundamental issue imo.
>
On 2020-07-17 10:46, Peter Eisentraut wrote:
v1-0001-Rename-configure.in-to-configure.ac.patch
I have committed that, and I have sent feedback to the Autoconf
developers about our concerns about the slowness of some of the new tests.
--
Peter Eisentraut http://www.2ndQuadrant.co
Hi All,
Attached is the patch that adds heap_force_kill(regclass, tid[]) and
heap_force_freeze(regclass, tid[]) functions which Robert mentioned in the
first email in this thread. The patch basically adds an extension named
pg_surgery that contains these functions. Please have a look and let me
k
On Thu, Jul 23, 2020 at 07:33:45PM -0700, Peter Geoghegan wrote:
On Thu, Jul 23, 2020 at 6:22 PM Tomas Vondra
wrote:
So let me share some fresh I/O statistics collected on the current code
using iosnoop. I've done the tests on two different machines using the
"aggregate part" of TPC-H Q17, i.e.
On Fri, 17 Jul 2020 at 13:23, osumi.takami...@fujitsu.com
wrote:
>
> Hi,
>
> > AFAICS, we can already accomplish basically the same thing as what you want
> > to
> > do like this:
> >
> > alter table foo set unlogged;
> > copy foo from ...;
> > alter table foo set logged;
> This didn't satisfy wh
The patch no longer applies, because of additions in the test source.
Otherwise, I have tested the patch and confirmed that updates and deletes on
tables with deferred primary keys work with logical replication.
The new status of this patch is: Waiting on Author
Sorry, I replied in the wrong thread. Please ignore above mail.
>
>
Hi, hackers
The source looks like:
case ECPGt_bytea:
{
struct ECPGgeneric_varchar *variable =
(struct ECPGgeneric_varchar *) (var->value);
..
}
I think the developer intend to use struct ECPGgeneric_bytea instead of str
The patch no longer applies, because of additions in the test source.
Otherwise, I have tested the patch and confirmed that updates and deletes on
tables with deferred primary keys work with logical replication.
The new status of this patch is: Waiting on Author
Hi Soumyadeep,
Thanks for re-running the tests.
On Thu, 23 Jul 2020 at 06:01, Soumyadeep Chakraborty
wrote:
> On Tue, Jul 14, 2020 at 8:52 PM David Rowley wrote:
> > It would be good to see EXPLAIN (ANALYZE, BUFFERS) with SET
> > track_io_timing = on; for each value of max_parallel_workers.
>
>
On Thu, Jul 23, 2020 at 12:54 PM vignesh C wrote:
>
> Thanks for reviewing and adding your thoughts, My comments are inline.
>
> On Fri, Jul 17, 2020 at 1:21 PM Bharath Rupireddy
> wrote:
> >
> > The same hang issue can occur(though I'm not able to back it up with a
> > use case), in the cases fr
70 matches
Mail list logo
