What's the current status of how much faster the Opteron is compared to the
Xeons? I know the Opterons used to be close to 2x faster, but is that still
the case? I understand much work has been done to reduce the contect
switching storms on the Xeon architecture, is this correct?
--
Jeff Fro
I have an application that is prone to sudden, unscheduled high bursts of
activity, and
I am finding that the application design permits me to detect the activity
bursts within
an existing function. The bursts only affect 3 tables, but degradation
becomes apparent
after 2,000 updates, and significa
On Thu, Oct 06, 2005 at 03:57:38PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Indeed, one of the things on my list is to remove all the lseeks in
> > favour of pread. Halving the number of kernel calls has got to be worth
> > something right? Portability is an issue ofcourse...
>
Martijn van Oosterhout writes:
> Are we awfully worried about people still using 2.0 kernels? And it
> would replace two calls with three in the worst case, we currently
> lseek before every read.
That's utterly false.
regards, tom lane
---(end of
Martijn van Oosterhout writes:
> Indeed, one of the things on my list is to remove all the lseeks in
> favour of pread. Halving the number of kernel calls has got to be worth
> something right? Portability is an issue ofcourse...
Being sure that it's not a pessimization is another issue. I note
On Thu, Oct 06, 2005 at 08:17:54AM -0500, Kelly Burkhart wrote:
> Given:
> - Processes which are connected to the database for long periods of time
> (transactions are always short).
> - These processes will use some functions to query data.
> - Lots of data is being inserted into tables that these
On Tue, 2005-10-04 at 03:10 -0700, Jan Aerts wrote:
> Some additional thoughts: what appears to take the most time (i.e.
> account for the highest cost in the explain), is _not_ running the
> function itself (cost=0.00..0.01), but comparing the result from that
> function with the name1 column in t
On Thu, Oct 06, 2005 at 08:56:31AM -0400, Ian Westmacott wrote:
> On Thu, 2005-10-06 at 02:39, Thomas F. O'Connell wrote:
> > The WAL Configuration chapter (25.2) has a pretty good discussion of
> > how wal_buffers is used:
> >
> > http://www.postgresql.org/docs/8.0/static/wal-configuration.html
I am working on a system which will be heavily dependent on functions
(some SQL, some PL/pgSQL). I am worried about the backend caching query
execution plans for long running connections.
Given:
- Processes which are connected to the database for long periods of time
(transactions are always shor
On Thu, 2005-10-06 at 02:39, Thomas F. O'Connell wrote:
> The WAL Configuration chapter (25.2) has a pretty good discussion of
> how wal_buffers is used:
>
> http://www.postgresql.org/docs/8.0/static/wal-configuration.html
>
> You might also take a look at Josh Berkus' recent testing on this
On Wed, Oct 05, 2005 at 04:55:51PM -0700, Luke Lonergan wrote:
You've proven my point completely. This process is bottlenecked in the CPU.
The only way to improve it would be to optimize the system (libc) functions
like "fread" where it is spending most of it's time.
Or to optimize its IO hand
Hi,
On Mon, Oct 03, 2005 at 08:14:11AM -0700, [EMAIL PROTECTED] wrote:
> So my questions are:
> * Does anyone have any idea how I can integrate a function that lists
> all aliases for a given name into such a mapping query?
what version are you using?
TIP 9: In versions below 8.0, the planner wi
12 matches
Mail list logo
