>> new release number, methinks there is plenty of room for confusion :(
>>>
>>> It might be an idea to update the "splash box" with details of the
>>> upcoming
>>> release.
>>
>>
>> I agree updating the "spash box" w
t; support Infinite Cache into mainline Postgres. If that ever happened you
> could build your own version of it.
>
> BTW, thanks to the compression feature of IC I've heard it can actually be
> beneficial to run it on the same server.
Correct.
--
Dave Page
Blog: http://pgsnake.b
ur workload is read intensive then the
speedups are potentially huge (I've seen benchmarks showing 20x+).
Write intensive workloads, less so, similarly if the working set is
far larger than your cache size.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http:/
ost
> RPMs safely.
FYI, we've just had more hardware converted to the new infrastructure
platform (literally last night), so hopefully we can provision this
machine soon.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
T
p
>
> I don't think we need a system-wide setting for that. I believe that
> the unlogged tables I'm working on will handle that case.
Aren't they going to be truncated at startup? If the entire system is
running without WAL, we would only need to do that in case of an
u
nd suggested I send a short ‘blast’
>
>
>
> If this works I’ll send a shortened version of my query later.
I got it. Try posting large query plans etc. to pastebin or a similar
service to keep the mail size down.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent vi
at if you really need to, either manually init a new cluster
using initdb, or do something like:
CREATE DATABASE foo WITH ENCODING 'SQL_ASCII' TEMPLATE template0;
to get a single database in SQL_ASCII.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-perfor
rvers on a variety of boxes. They're not a budget outfit though, but
that's reflected in the service.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
cannot compare psql and pgAdmin's
timings because the architectures of the two apps are very different.
Further, pgAdmin isn't the best choice for micro-optimisation of
extremely fast queries.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent via pgsql-performance mail
the query from pgadmin3 on a remote host. The
>> server has nothing else running on it except the database.
>
> pgadmin has got its own performance issues with large select results.
They were fixed a couple of years ago. We're essentially at the mercy
of libpq now.
--
Dave Page
o spend the next hour
cleaning coffee out of my laptop keyboard.
:-)
--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chan
Robert Bernabe wrote:
> I'm happy (actually ecstatic) to report that Win2kPro + PG performance
> is slightly faster than Win2kPro + MSSQL/MSDE.
>
> Linux(FC7) + PG 8.x performance seems to be 3x faster than Win2KPro +
> MSSQL/MSDE for our stored functions.
>
> Thanks for all the help! Am a belie
Mark Cave-Ayland wrote:
> BTW you mention both EnterpriseDB PostgreSQL 8.3 beta and just
> PostgreSQL 8.3 beta in the text above. Both of these are different -
> which one are you actually using?
No they're not. EnterpriseDB Postgres ships entirely standard binaries -
in fact, the Windows build us
Campbell, Lance wrote:
All of the fields are zero except for the three I listed in my posting.
Do you have the stats collector enabled, and row & block level stats
turned on?
Regards, Dave.
---(end of broadcast)---
TIP 4: Have you searched our
> --- Original Message ---
> From: Jean-Max Reymond <[EMAIL PROTECTED]>
> To: pgsql-performance@postgresql.org
> Sent: 24/07/07, 18:23:53
> Subject: Re: [PERFORM] Table Statistics with pgAdmin III
>
> Campbell, Lance a écrit :
> > I have installed pgAdmin III 1.6. In the tool when you c
Dave Page wrote:
I don't see why pgAdmin should be slow though - it should be only
marginally slower than psql I would think (assuming there are no thinkos
in our code that none of use ever noticed).
Nevermind...
/D
---(end of broa
Rainer Bauer wrote:
It's not immediately clear why pgAdmin would have the same issue,
though, because AFAIK it doesn't rely on ODBC.
No it doesn't. That's the reason I used it to verify the behaviour.
But I remember Dave Page mentioning using a virtual list control to dis
Tom Lane wrote:
There's another reason for not setting shared_buffers huge, beyond the
good ones Greg listed: the kernel may or may not consider a large
shared-memory segment as potentially swappable.
Another is that on Windows, shared memory access is more expensive and
various people have
Joost Kraaijeveld wrote:
> On Tue, 2007-05-29 at 21:43 +0100, Dave Page wrote:
>> Cliff, Jason or Rob era? Could be important...
> Cliff and Jason.
>
> Rob is in my Ozzy collection ;-)
And rightly so imho.
:-)
/D
---(end of broadcast)---
Joost Kraaijeveld wrote:
> Hi
>
> I am currently running a vacuum analyse through PgAdmin on a PostgreSQL
> 8.1.9 database that takes forever without doing anything: no
> (noticeable) disk activity or (noticeable) CPU activity.
>
> The mesage tab in PgAdmin says:
>
> ...
> Detail: 0 index page
> --- Original Message ---
> From: Josh Berkus <[EMAIL PROTECTED]>
> To: pgsql-performance@postgresql.org
> Sent: 03/05/07, 20:21:55
> Subject: Re: [PERFORM] Feature Request --- was: PostgreSQL Performance Tuning
>
>
> And let's not even get started on Windows.
WMI is your friend.
/D
Oleg Bartunov wrote:
> Guys, current tsearch2 should works with millions of documents.
...
> Search itself is incredibly fast !
Oh, I know - you and Teodor have done a wonderful job.
Regards, Dave.
---(end of broadcast)---
TIP 3: Have you check
Steinar H. Gunderson wrote:
> On Tue, Feb 27, 2007 at 01:33:47PM +0000, Dave Page wrote:
>> When we outgrow PostgreSQL & Tsearch2, then, well, we'll need to stop
>> pretending to be Google...
>
> Just for the record: Google has been known to sponsor sites in nee
Charles Sprickman wrote:
> On Tue, 27 Feb 2007, Dave Page wrote:
>
>> Magnus Hagander wrote:
>>>
>>> Just as a datapoint, we did try to use mnogosearch for the
>>> postgresql.org website+archives search, and it fell over completely.
>>> Indexing to
Magnus Hagander wrote:
>
> Just as a datapoint, we did try to use mnogosearch for the
> postgresql.org website+archives search, and it fell over completely.
> Indexing took way too long, and we had search times several thousand
> times longer than with tsearch2.
>
> That said, I'm sure there are
> -Original Message-
> From: Scott Marlowe [mailto:[EMAIL PROTECTED]
> Sent: 14 June 2006 20:52
> To: Dave Page
> Cc: Joshua D. Drake; [EMAIL PROTECTED];
> pgsql-performance@postgresql.org
> Subject: RE: [PERFORM] Which processor runs better for Postgresql?
>
for Postgresql?
On Tue, 2006-06-13 at 15:11, Dave Page
wrote:> > > -Original Message-> And
how old are the 2600's now?>> Anyhoo, I'm not saying the current
machines are excellent performers or> anything, but there are good
business reasons to
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joshua D. Drake
> Sent: 13 June 2006 20:44
> To: Scott Marlowe
> Cc: [EMAIL PROTECTED]; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Which processor runs better for Postgresql?
>
> T
-Original Message-
From: "Luke Lonergan"<[EMAIL PROTECTED]>
Sent: 19/03/06 16:26:58
To: "Kenji Morishige"<[EMAIL PROTECTED]>, "Claus Guttesen"<[EMAIL PROTECTED]>
Cc: "pgsql-performance@postgresql.org"
Subject: Re: [PERFORM] Best OS & Configuration for Dual Xeon w/4GB &
> I notice that no
On 7/3/06 18:45, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 06, 2006 at 01:14:45PM -0400, Marc G. Fournier wrote:
>> We host VPSs here (http://www.hub.org) and don't use the 'single file,
>> virtual file system' to put them into ... it must depend on where you
>> host?
>
> Yeah, b
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Vivek Khera
> Sent: 08 December 2005 16:52
> To: Postgresql Performance
> Subject: [PERFORM] opinion on disk speed
>
> I have a choice to make on a RAID enclosure:
>
> 14x 36GB 15kRPM ultra 320
> -Original Message-
> From: Joost Kraaijeveld [mailto:[EMAIL PROTECTED]
> Sent: 07 November 2005 09:03
> To: Dave Page
> Cc: Tom Lane; Pgsql-Performance
> Subject: RE: [PERFORM] Performance PG 8.0 on dual opteron /
> 4GB / 3ware
>
> > Nothing - it jus
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joost Kraaijeveld
> Sent: 07 November 2005 04:26
> To: Tom Lane
> Cc: Pgsql-Performance
> Subject: Re: [PERFORM] Performance PG 8.0 on dual opteron /
> 4GB / 3ware
>
> Hi Tom,
>
> On Sun, 2005-
On 1/11/05 2:50 pm, "Jon Brisbin" <[EMAIL PROTECTED]> wrote:
> On Mon, 31 Oct 2005 17:16:46 -0600
> "PostgreSQL" <[EMAIL PROTECTED]> wrote:
>
>> We're running 8.1beta3 on one server and are having ridiculous
>> performance issues. This is a 2 cpu Opteron box and both processors
>> are staying
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: 28 April 2005 04:09
> To: Dave Page
> Cc: Joshua D. Drake; Joel Fradkin; PostgreSQL Perform
> Subject: Re: [PERFORM] Final decision
>
> Dave, folks,
>
> > Err, yes. But
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: 27 April 2005 17:46
> To: Dave Page
> Cc: Josh Berkus; Joel Fradkin; PostgreSQL Perform
> Subject: Re: [PERFORM] Final decision
>
> > It is? No-one told the developers...
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Josh Berkus
> Sent: 27 April 2005 17:14
> To: Joel Fradkin
> Cc: PostgreSQL Perform
> Subject: Re: [PERFORM] Final decision
>
> Actually, I think the problem may be ODBC. Our ODBC driver
> is
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andreas Pflug
> Sent: 21 April 2005 14:06
> To: Joel Fradkin
> Cc: 'John A Meinel'; josh@agliodbs.com;
> pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Joel's Performance Issues WAS :
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joel Fradkin
> Sent: 18 April 2005 14:02
> To: PostgreSQL Perform
> Subject: FW: [PERFORM] speed of querry?
>
> Another odd thing is when I tried turning off merge joins on
> the XP desktop
> It
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Matthew Nuzum
> Sent: 12 April 2005 17:25
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] performance hit for replication
>
> So, my question is this: My server currently works great,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Tom Lane
> Sent: 07 March 2005 22:57
> To: John A Meinel
> Cc: Dave Held; pgsql-performance@postgresql.org;
> [EMAIL PROTECTED]
> Subject: Re: [pgsql-hackers-win32] [PERFORM] Help with tuning
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Bruce Momjian
> Sent: 23 November 2004 02:26
> To: Merlin Moncure
> Cc: [EMAIL PROTECTED]; PostgreSQL Win32 port list
> Subject: Re: [pgsql-hackers-win32] scalability issues on win32
>
>
> This
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 23 November 2004 15:06
> To: Dave Page
> Cc: Merlin Moncure; [EMAIL PROTECTED];
> PostgreSQL Win32 port list
> Subject: Re: [pgsql-hackers-win32] scalability issues on win32
>
> Th
43 matches
Mail list logo
