Hi,
On 2018-11-29 16:54:14 +0100, Dmitry Dolgov wrote:
> > On Tue, Sep 25, 2018 at 1:04 AM Joe Wildish
> > wrote:
> >
> > All agreed. I’ll give the patch some TLC and get a new version that
> > addresses the above.
>
> Hi,
>
> Just a reminder, that the patch still needs to be rebased, could yo
> On Tue, Sep 25, 2018 at 1:04 AM Joe Wildish
> wrote:
>
> All agreed. I’ll give the patch some TLC and get a new version that
> addresses the above.
Hi,
Just a reminder, that the patch still needs to be rebased, could you please do
this? I'm moving the item to the next CF.
> "Joe" == Joe Wildish writes:
>> I haven't looked at the background of this, but if what you want to
>> know is whether the aggregate function has the semantics of min() or
>> max() (and if so, which) then the place to look is
>> pg_aggregate.aggsortop.
Joe> Thanks for the pointer. I'v
Hi David,
> On 26 Sep 2018, at 19:47, David Fetter wrote:
>
>> Invalidating operations are "INSERT(t) and UPDATE(t.b, t.n)".
>
> So would DELETE(t), assuming n can be negative.
Oops, right you are. Bug in my implementation :-)
> Is there some interesting and fairly easily documented subset o
Hi Andrew,
On 25 Sep 2018, at 01:51, Andrew Gierth wrote:
> I haven't looked at the background of this, but if what you want to know
> is whether the aggregate function has the semantics of min() or max()
> (and if so, which) then the place to look is pg_aggregate.aggsortop.
Thanks for the point
On 26 Sep 2018, at 12:36, Peter Eisentraut
wrote:
>
> On 25/09/2018 01:04, Joe Wildish wrote:
>> Having said all that: there are obviously going to be some expressions
>> that cannot be proven to have no potential for invalidating the assertion
>> truth. I guess this is the prime concern from a
On Tue, Sep 25, 2018 at 12:04:12AM +0100, Joe Wildish wrote:
> Hi Peter,
>
> > My feeling is that if we want to move forward on this topic, we need to
> > solve the concurrency question first. All these optimizations for when
> > we don't need to check the assertion are cool, but they are just
>
On 25/09/2018 01:04, Joe Wildish wrote:
> Having said all that: there are obviously going to be some expressions
> that cannot be proven to have no potential for invalidating the assertion
> truth. I guess this is the prime concern from a concurrency PoV?
Before we spend more time on this, I think
> "Joe" == Joe Wildish writes:
Joe> Agreed. My assumption was that we would record in the data
Joe> dictionary the behaviour (or “polarity") of each aggregate
Joe> function with respect to the various operators. Column in
Joe> pg_aggregate? I don’t know how we’d record it exactly.
I have
Hi Peter,
> On 24 Sep 2018, at 15:06, Peter Eisentraut
> wrote:
>
> On 29/04/2018 20:18, Joe Wildish wrote:
>>
>> Attached is a rebased patch for the prototype.
>
> I took a look at this.
Thank you for reviewing.
> This has been lying around for a few months, so it will need to be
> rebased
On 29/04/2018 20:18, Joe Wildish wrote:
> On 28 Mar 2018, at 16:13, David Fetter wrote:
>>
>> Sorry to bother you again, but this now doesn't compile atop master.
>
> Attached is a rebased patch for the prototype.
I took a look at this.
This has been lying around for a few months, so it will ne
On Sun, Apr 29, 2018 at 07:18:00PM +0100, Joe Wildish wrote:
> On 28 Mar 2018, at 16:13, David Fetter wrote:
> >
> > Sorry to bother you again, but this now doesn't compile atop master.
>
> Attached is a rebased patch for the prototype.
Thanks!
This is great timing for the 12 cycle :)
Best,
D
On Sun, Mar 18, 2018 at 12:29:50PM +, Joe Wildish wrote:
> >
> >>
> >> This patch no longer applies. Any chance of a rebase?
>
> Attached is a rebased version of this patch. It takes into account
> the ACL checking changes and a few other minor amendments.
Sorry to bother you again, but th
On Sun, Mar 18, 2018 at 12:29:50PM +, Joe Wildish wrote:
> >
> >>
> >> This patch no longer applies. Any chance of a rebase?
> >>
> >
>
>
> Attached is a rebased version of this patch. It takes into account the ACL
> checking changes and a few other minor amendments.
Thanks!
Best,
Dav
On Sat, Mar 10, 2018 at 6:37 AM, Robert Haas wrote:
> On Mon, Jan 15, 2018 at 11:35 AM, David Fetter wrote:
>> - We follow the SQL standard and make SERIALIZABLE the default
>> transaction isolation level, and
>
> The consequences of such a decision would include:
>
> - pgbench -S would run up
On Mon, Jan 15, 2018 at 11:35 AM, David Fetter wrote:
> - We follow the SQL standard and make SERIALIZABLE the default
> transaction isolation level, and
The consequences of such a decision would include:
- pgbench -S would run up to 10x slower, at least if these old
benchmark results are stil
On Thu, Mar 08, 2018 at 09:11:58PM +, Joe Wildish wrote:
> Hi David,
>
> >
> > This patch no longer applies. Any chance of a rebase?
>
> Of course. I’ll look at it this weekend,
Much appreciate it!
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Hi David,
>
> This patch no longer applies. Any chance of a rebase?
>
Of course. I’ll look at it this weekend,
Cheers,
-Joe
On Mon, Jan 15, 2018 at 09:14:02PM +, Joe Wildish wrote:
> Hi David,
>
> > On 15 Jan 2018, at 16:35, David Fetter wrote:
> >
> > It sounds reasonable enough that I'd like to make a couple of Modest
> > Proposals™, to wit:
> >
> > - We follow the SQL standard and make SERIALIZABLE the defaul
Hi David,
> On 15 Jan 2018, at 16:35, David Fetter wrote:
>
> It sounds reasonable enough that I'd like to make a couple of Modest
> Proposals™, to wit:
>
> - We follow the SQL standard and make SERIALIZABLE the default
> transaction isolation level, and
>
> - We disallow writes at isolation
On Mon, Jan 15, 2018 at 03:40:57PM +0100, Fabien COELHO wrote:
>
> >>I'm wondering about the effect of MVVC on this: if the check is
> >>performed when the INSERT is done, concurrent inserting transactions
> >>would count the current status which would be ok, but on commit all
> >>concurrent inser
I'm wondering about the effect of MVVC on this: if the check is
performed when the INSERT is done, concurrent inserting transactions
would count the current status which would be ok, but on commit all
concurrent inserts would be there and the count could not be ok
anymore?
The patch doesn’t
Hi Fabien,
>> * certain combinations of aggregates with comparison operations cannot be
>> invalidating.
>>
>> As an example of the last point, the expression "CHECK (10 > (SELECT
>> COUNT(*) FROM t))" cannot be invalidated by a delete or an update but can be
>> invalidated by an insert.
>
>
Hello Joe,
Just a reaction to the example, which is maybe addressed in the patch
which I have not investigated.
* certain combinations of aggregates with comparison operations cannot
be invalidating.
As an example of the last point, the expression "CHECK (10 > (SELECT
COUNT(*) FROM t))" c
24 matches
Mail list logo
