Jonah H. Harris wrote:
On 8/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
UPDATE tries to place the new tuple on the same page it's already
on.
I think he meant for INSERT.
Right. Update is indeed taken care of already.
One example where this would help would be a customer_history table that
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2006-08-09 at 10:04 -0400, Tom Lane wrote:
>> Another option is to have pg_current_xlog_location force a write (but
>> not fsync) as far as the Insert pointer it's about to return. This
>> would eliminate any issues about inconsistency between resu
On Wed, Aug 09, 2006 at 09:53:08PM -0400, Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
Bruce
On 8/5/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Here's the updated patch with DELETE RETURNING removed. This isn't
> really an issue because no one wanted DELETE RETURNING to begin with.
I don't have the time to add DELETE RETURNING back in. My i
Gene <[EMAIL PROTECTED]> writes:
> "Your best bet might be to partition the table into two subtables, one
> with "stable" data and one with the fresh data, and transfer rows from
> one to the other once they get stable. Storage density in the "fresh"
> part would be poor, but it should be small
Ah, I see that now. Thanks.
---
David Fetter wrote:
> On Wed, Aug 09, 2006 at 09:53:08PM -0400, Bruce Momjian wrote:
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjia
