On 30 Apr. 2017 13:28, "Andres Freund" wrote:
On 2017-04-30 00:28:46 -0400, Tom Lane wrote:
> There's already a pretty large hill to climb here in the way of
> breaking peoples' expectations about CTEs being optimization
> fences. Breaking the documented semantics about CTEs being
> single-evalu
On 2017-04-30 00:28:46 -0400, Tom Lane wrote:
> There's already a pretty large hill to climb here in the way of
> breaking peoples' expectations about CTEs being optimization
> fences. Breaking the documented semantics about CTEs being
> single-evaluation seems to me to be an absolute non-starter.
2017-04-30 6:28 GMT+02:00 Tom Lane :
> Craig Ringer writes:
> > - as you noted, it is hard to decide when it's worth inlining vs
> > materializing for CTE terms referenced more than once.
>
> [ raised eyebrow... ] Please explain why the answer isn't trivially
> "never".
>
> There's already a pre
Craig Ringer writes:
> - as you noted, it is hard to decide when it's worth inlining vs
> materializing for CTE terms referenced more than once.
[ raised eyebrow... ] Please explain why the answer isn't trivially
"never".
There's already a pretty large hill to climb here in the way of
breaking
On 30 Apr. 2017 07:56, "Ilya Shkuratov" wrote:
Hello, dear hackers!
There is task in todo list about optional CTE optimization fence
disabling.
I am not interested at this point in disabling mechanism
implementation, but I would like to discuss the optimization
mechanism, that should work when
Thomas Munro writes:
> I was reading xact.c and noticed this block:
> ...
> Isn't this insufficient on non-TSO systems like POWER and Arm?
Yeah, I think you're right. That code probably predates our support
for memory barriers, so "volatile" was the best we could do at the
time --- but as you sa
Hi hackers,
I was reading xact.c and noticed this block:
/*
* Use volatile pointer to prevent code rearrangement;
other backends
* could be examining my subxids info concurrently,
and we don't want
* them to see an invalid interme
David Rowley writes:
> On 29 April 2017 at 15:39, Tom Lane wrote:
>> I'm kind of strongly tempted to apply the second patch; but it would
>> be fair to complain that reduce_unique_semijoins() is new development
>> and should wait for v11. Opinions?
> My vote is for the non-minimal patch. Of cou
On 29 April 2017 at 15:39, Tom Lane wrote:
> I'm kind of strongly tempted to apply the second patch; but it would
> be fair to complain that reduce_unique_semijoins() is new development
> and should wait for v11. Opinions?
My vote is for the non-minimal patch. Of course, I'd be voting for
minima
Hello, dear hackers!
There is task in todo list about optional CTE optimization fence
disabling.
I am not interested at this point in disabling mechanism
implementation, but I would like to discuss the optimization
mechanism, that should work when the fence is disabled.
It seems, that we can
On Fri, Apr 21, 2017 at 10:34:58PM -0700, Andres Freund wrote:
> I've a bunch of tests, but I don't quite know whether we can expose all
> of them via classical tests. There are several easy ones that I
> definitely want to add (import "empty" snapshot; import snapshot with
> running xacts; create
On 23/04/17 01:10, Petr Jelinek wrote:
> Hi,
>
> The time based lag tracking commit [1] added interface for logging
> progress of replication so that we can report lag as time interval
> instead of just bytes. But the patch didn't contain patch for the
> builtin logical replication.
>
> So I wrot
On Tue, Apr 25, 2017 at 03:26:06PM -0400, Peter Eisentraut wrote:
> On 4/20/17 11:30, Peter Eisentraut wrote:
> > On 4/19/17 23:04, Noah Misch wrote:
> >> This PostgreSQL 10 open item is past due for your status update. Kindly
> >> send
> >> a status update within 24 hours, and include a date for
Really, the way to fix Teodor's complaint is to recognize that the
semijoin inner rel is effectively unique against the whole outer rel,
and then strength-reduce the semijoin to a plain join. The infrastructure
we built for unique joins is capable of proving that, we just weren't
applying it in t
Dmitriy Sarafannikov writes:
>> Maybe we need another type of snapshot that would accept any
>> non-vacuumable tuple. I really don't want SnapshotAny semantics here,
> If I understood correctly, this new type of snapshot would help if
> there are long running transactions which can see this tupl
> Maybe we need another type of snapshot that would accept any
> non-vacuumable tuple. I really don't want SnapshotAny semantics here,
> but a tuple that was live more recently than the xmin horizon seems
> like it's acceptable enough. HeapTupleSatisfiesVacuum already
> implements the right beha
16 matches
Mail list logo
