From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Lester <joe_lester(at)sweetwater(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Using NOTIFY... Slow Client Querys |
Date: | 2004-02-15 17:07:28 |
Message-ID: | 8822.1076864848@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joe Lester <joe_lester(at)sweetwater(dot)com> writes:
> I'm using PostgreSQL 7.4.1. I have 140 clients connected on average
> using libpq. When one client sends "NOTIFY timeclock;" to the server
> all 140 clients are listening for it.
> After receiving a notification from libpq (PQnotifies), each client
> proceeds to execute a query for the last five records in the timeclock
> table.
> SELECT * FROM timeclock ORDER BY touched DESC LIMIT 5;
> It varies, but it's often the case that clients wait up to 3 minutes
> before the results come back. This seems like a really long time for a
> query that I would think would go quickly. In fact, I can execute the
> same query from a third party client and it runs fine, even while my
> own client is still waiting for results.
Hmm. Are you certain that the clients have received the NOTIFY?
Perhaps the bottleneck is in delivering the NOTIFY messages, not in
executing the subsequent query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-15 17:18:48 | Re: nonblocking libpq large object access? |
Previous Message | Tom Lane | 2004-02-15 17:05:08 | Re: timestamp/date comparison |