"Simon Riggs" <[EMAIL PROTECTED]> writes:
> ...and of course it would be good if LISTEN/NOTIFY were able to use this
> concept also, to help Slony along also.
LISTEN/NOTIFY are overdue to be rewritten to not use a table at all,
so I'm not particularly worried about whether this idea is applicable
Quoth [EMAIL PROTECTED] ("Simon Riggs"):
> On Tue, 2006-11-07 at 15:00 +1300, Mark Kirkwood wrote:
>> Simon Riggs wrote:
>> > EnterpriseDB has been running a research project to improve the
>> > performance of heavily updated tables. We have a number of approaches
>> > prototyped and we'd like to d
On Tue, 2006-11-07 at 15:00 +1300, Mark Kirkwood wrote:
> Simon Riggs wrote:
> > EnterpriseDB has been running a research project to improve the
> > performance of heavily updated tables. We have a number of approaches
> > prototyped and we'd like to discuss the best of these now on -hackers
> > fo
On Thu, 2006-11-09 at 04:09 -0500, Andrew Sullivan wrote:
> On Mon, Nov 06, 2006 at 09:50:53PM +, Simon Riggs wrote:
> > - There are specific issues with the optimizer's ability to understand
> > dead row numbers, which can in some cases lead to SeqScan plans that are
> > inappropriate when ta
On Mon, Nov 06, 2006 at 09:50:53PM +, Simon Riggs wrote:
> - There are specific issues with the optimizer's ability to understand
> dead row numbers, which can in some cases lead to SeqScan plans that are
> inappropriate when tables grow because of updates. This is a red-herring
> that can lea
On Tue, 2006-11-07 at 13:02 +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>
> > EnterpriseDB has been running a research project to improve the
> > performance of heavily updated tables. We have a number of approaches
> > prototyped and we'd like to discuss the best of
"Simon Riggs" <[EMAIL PROTECTED]> wrote:
> EnterpriseDB has been running a research project to improve the
> performance of heavily updated tables. We have a number of approaches
> prototyped and we'd like to discuss the best of these now on -hackers
> for community input and patch submission to P
Simon Riggs wrote:
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now on -hackers
for community input and patch submission to PostgreSQL core.
Excellent!
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now on -hackers
for community input and patch submission to PostgreSQL core.
The most important step with any
