Tom Lane <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > Short answer: MVCC tuple visibility status isn't (and can't be) stored
> > in the index.
>
> Well, in principle it *could* be, but there are strong arguments why it
> shouldn't be: the costs of updating N index e
On Sep 8, 2004, at 2:58 PM, Neil Conway wrote:
I've accepted an offer from Fujitsu Australia Software Technologies to
work on PostgreSQL full-time for them for the next twelve months in
Sydney, Australia. I'll be working with Gavin Sherry and two other
full-time developers from FAST. I'm gratefu
I've accepted an offer from Fujitsu Australia Software Technologies to
work on PostgreSQL full-time for them for the next twelve months in
Sydney, Australia. I'll be working with Gavin Sherry and two other
full-time developers from FAST. I'm grateful to Fujitsu for giving me
the opportunity to
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Hmm, if our current state of deferred triggers look like (in order)
> > Trigger A
> > Trigger B
> > Trigger C
>
> > and triggers A and B are made immediate and scanning begins at the
> > beginning of the queue
Doug McNaught <[EMAIL PROTECTED]> writes:
> Short answer: MVCC tuple visibility status isn't (and can't be) stored
> in the index.
Well the "can't" part is false or at least unproven. From prior discussion the
only thing that would be technically challenging would be avoiding deadlocks.
The m
Doug McNaught <[EMAIL PROTECTED]> writes:
> Short answer: MVCC tuple visibility status isn't (and can't be) stored
> in the index.
Well, in principle it *could* be, but there are strong arguments why it
shouldn't be: the costs of updating N index entries instead of just one
tuple entry, the potent
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Tue, Sep 07, 2004 at 07:58:56PM -0400, Doug McNaught wrote:
>> Hard to say how it would work, but come up with a good design and
>> quality patch and it'll probably go in. :)
>
> Probably not. This has been discussed before; what's needed is that
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Hmm, if our current state of deferred triggers look like (in order)
> Trigger A
> Trigger B
> Trigger C
> and triggers A and B are made immediate and scanning begins at the
> beginning of the queue again, during the execution of the Trigger A
> trigge
On Tue, Sep 07, 2004 at 07:58:56PM -0400, Doug McNaught wrote:
> Tiago Wright <[EMAIL PROTECTED]> writes:
> > Yes, thanks Tom. This is precisely what I was missing. I searched the
> > archives for the reason why this is so, but I found only one message
> > mentioning the MVCC mechanism. Can you po
Tiago Wright <[EMAIL PROTECTED]> writes:
> Yes, thanks Tom. This is precisely what I was missing. I searched the
> archives for the reason why this is so, but I found only one message
> mentioning the MVCC mechanism. Can you point me in the right
> direction? I would like to understand the issue.
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I misread then. I thought that you were proposing that EndQuery look only
> > at the per-query list and then add the deferred items that weren't fired
> > to the main list but never go over that list.
>
> It will
> > where productname is in the product table, and lotname in the lot
> > table. I would be interested in creating an index such as
>
> > CREATE INDEX ix_vw_lot ON vw_lot (lotname, productname);
>
> What purpose would this serve that indexes on the separate tables
> wouldn't serve?
>
> > The ind
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
I was just noticing that pg_stat_activity is truncating queries which are
logged to it at about 150 chars.
256, I would expect.
I can't think of any good reason for this.
There is good reason to limit the packet size, but to a kilobyte or
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I misread then. I thought that you were proposing that EndQuery look only
> at the per-query list and then add the deferred items that weren't fired
> to the main list but never go over that list.
It will have to re-examine the tail of the main list, as
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If I'm reading the above correctly, I think DeferredTriggerSetState may
> > need to change a little if EndQuery works on a separate list of triggers
> > because I believe set constraints immediate currently depends
So what is the thinking of HACKERS?
Does it make sense to include nothing and rather allow each
distribution to support its own?
Or should each distribution known to support postgres be invited to
submit the relevant script for inclusion? And, if so, should this be a
HACKERS [or other appropria
Josh Berkus <[EMAIL PROTECTED]> writes:
> I was just noticing that pg_stat_activity is truncating queries which are
> logged to it at about 150 chars.
256, I would expect.
> I can't think of any good reason for this.
There is good reason to limit the packet size, but to a kilobyte or so.
Feel f
Stephan Szabo <[EMAIL PROTECTED]> writes:
> If I'm reading the above correctly, I think DeferredTriggerSetState may
> need to change a little if EndQuery works on a separate list of triggers
> because I believe set constraints immediate currently depends on EndQuery
> going over the entire list of
Folks,
I was just noticing that pg_stat_activity is truncating queries which are
logged to it at about 150 chars. I can't think of any good reason for this.
Is there one?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
On Tue, 7 Sep 2004, Tom Lane wrote:
> * EndQuery processes and discards immediate-mode AFTER trigger events for the
> current query. Any remaining events (ie, DEFERRED triggers) are appended
> to the current (sub)transaction's list of pending deferred triggers.
> Note that even inside a subtrans
Here's another thing that I think it would be good to fix in 8.0.
We've had numerous complaints before about RI constraints not firing
inside PL functions; a recent one is
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php
I think also that the current behavior violates the SQL spec.
S
On Mon, 6 Sep 2004, Tom Lane wrote:
> Surely the sense of this is backwards, and it should be
>
> if (!(event->dte_event & TRIGGER_DEFERRED_CANCELED) &&
> !(event->dte_event & TRIGGER_DEFERRED_DONE &&
> TransactionIdIsValid(event->dte_done_xid) &&
>
22 matches
Mail list logo
