Flemming Frandsen wrote:
> Christopher Browne wrote:
> >There's a demerit:
> >c) If there are a LOT of events, that might not fit in memory nicely.
>
> If you have that many events then the current implementation is going to
> suck hard as well:)
The difference is that the current implementation
Christopher Browne wrote:
There's a demerit:
c) If there are a LOT of events, that might not fit in memory nicely.
If you have that many events then the current implementation is going to
suck hard as well:)
Keeping the listener structure in memory wouldn't be too bad.
I'd guess that each c
The world rejoiced as [EMAIL PROTECTED] (Tom Lane) wrote:
> Flemming Frandsen <[EMAIL PROTECTED]> writes:
>> I just looked at the pg_listener table:
>> ... and noticed the complete lack of indexen, surely this must be a bug?
>
> No, that was intentional. It's been a long time but I think the
> arg
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Flemming
Frandsen) wrote:
> I just looked at the pg_listener table:
>
> zepong-> \d+ pg_listener
> Table "pg_catalog.pg_listener"
> Column| Type | Modifiers | Description
> --+-+---+---
Flemming Frandsen <[EMAIL PROTECTED]> writes:
> I just looked at the pg_listener table:
> ... and noticed the complete lack of indexen, surely this must be a bug?
No, that was intentional. It's been a long time but I think the
argument was that the cost of updating the indexes would outweigh
thei
Michael Fuhr wrote:
What's the output of "VACUUM VERBOSE pg_listener"? If you vacuum
pg_listener do the listens run faster?
Actually now that You mentioned vacuming, I tried doing a VACUUM and
after it was done request time was down to around a tenth of what it was
before.
iow. requests th
Michael Fuhr wrote:
How long is "a very long time"?
More than 2ms, typically 50-150ms.
The other queries (that actually fetch data from tables and do real
work) execute in 1-4ms.
The funny thing is that if I run the select 6*7 after ping (which does a
select 'somestring') then the select 6
On Sat, Jul 29, 2006 at 12:44:14PM +0200, Flemming Frandsen wrote:
> Michael Fuhr wrote:
> >Also, based on a 60ms-per-listen time I suspect you're not doing
> >the listens in a transaction, so each listen is its own transaction
> >that has to be committed, resulting in a disk hit. Try doing them
>
Michael Fuhr wrote:
Also, based on a 60ms-per-listen time I suspect you're not doing
the listens in a transaction, so each listen is its own transaction
that has to be committed, resulting in a disk hit. Try doing them
all in one transaction.
I think I am doing the listens in a transaction, a
On Fri, Jul 28, 2006 at 10:09:00PM -0400, Alvaro Herrera wrote:
> Flemming Frandsen wrote:
> > The strange thing is that just about any query runs in 1-4ms, but the
> > listen command, which shouldn't even have to touch the disk takes around
> > 60ms.
>
> Actually, it does write to disk, because
Flemming Frandsen wrote:
> I cache a lot of data in the application, to invalidate that cache I
> have triggers that use notify to let new transactions eject the objects
> from the cache.
>
> My problem with listen is that when I start a new connection I run a
> listen command for each of my ta
11 matches
Mail list logo
