On Thu, Mar 27, 2008 at 03:14:49PM -0400, Dave Cramer wrote:
> I have a query which is
>
> prepare s_18 as select uid from user_profile where name like
> $1::varchar and isactive=$2 order by name asc limit 250;
>
> explain analyze execute s_18 ('atxchery%','t');
>
On Tue, 6 Mar 2007, lissette wrote:
> 2007-02-02 16:41:03 [Thread-6]message(s) in mail box>
> 2007-02-02 16:41:13 [Thread-39 ]an ebxml message from mail box>
> 2007-02-02 16:41:13 [Thread-39 ]
>
> 2007-02-02 16:41:14 [Thread-39 ]outgoing message: [EMAIL PROTECTED]>
> 2007-
Hi Brian,
On Thu, 18 Jan 2007, Brian Hurt wrote:
> Is there any experience with Postgresql and really huge tables? I'm
> talking about terabytes (plural) here in a single table. Obviously the
> table will be partitioned, and probably spread among several different
> file systems. Any other tri
On Tue, 18 Jul 2006, Rusty Conover wrote:
> Hi,
>
> It would seem that doing any changes on a temp table forces a copy of
> the entire contents of the table to be retained in memory/disk. Is
> this happening due to MVCC? Is there a way to change this behavior?
> It could be very useful when you
On Thu, 20 Apr 2006, Brendan Duddridge wrote:
> Hi Tomas,
>
> Hmm... ktrace -p PID -c returns immediately without doing anything
> unless I've previously done a ktrace -p PID.
>
> According to the man page for ktrace's -c flag:
>-c Clear the trace points associated with the specified file
On Mon, 13 Mar 2006, Dave Dutcher wrote:
> [Snip]
> > >
> > > shared_buffers = 256
> >
> > Make this higher too. If this is a dedicated machine with 512 MB of
> ram,
> > set it to something like 125000.
> >
> > You may need to adjust shared memory settings for your operating
> system.
> > See the
On Tue, 14 Mar 2006, Chris wrote:
> Hi all,
>
> I'm trying to work out why my 8.1 system is slower than my 7.4 system
> for importing data.
>
> The import is a lot of "insert into" commands - it's a converted
> database from another system so I can't change it to copy commands.
>
>
> My uncommente
On Thu, 15 Dec 2005, Harry Jackson wrote:
> Hi all,
> I have been using PostgreSQL (currently 7.4.7) for several years now and
> am very happy with it but I currently run a website that has had a
> little bit of a boost and I am starting to see some performance problems
> (Not necessarily Postgre
On Tue, 1 Nov 2005, Joost Kraaijeveld wrote:
> Hi Gavin,
>
> Thanks for answering.
>
> On Tue, 2005-11-01 at 20:16 +1100, Gavin Sherry wrote:
> > On Tue, 1 Nov 2005, Joost Kraaijeveld wrote:
> > > 1. Is there a repository somewhere that shows results, using and
>
On Tue, 1 Nov 2005, Joost Kraaijeveld wrote:
> Hi,
>
> I am trying to optimize my Debian Sarge AMD64 PostgreSQL 8.0
> installation, based on the recommendations from "the Annotated
> POSTGRESQL.CONF Guide for
> PostgreSQL"
> (http://www.powerpostgresql.com/Downloads/annotated_conf_80.html). To se
On Thu, 29 Sep 2005, Joe wrote:
> Magnus Hagander wrote:
> > That actually depends a lot on *how* you use it. I've seen pg-on-windows
> > deployments that come within a few percent of the linux performance.
> > I've also seen those that are absolutely horrible compared.
> >
> > One sure way to kil
On Wed, 28 Sep 2005, Joe wrote:
> I'm converting a relatively small database (2 MB) from MySQL to PostgreSQL.
> It
> is used to generate web pages using PHP. Although the actual website runs
> under
> Linux, the development is done under XP. I've completed most of the data
> conversion and re
On Thu, 29 Sep 2005, Rajesh Kumar Mallah wrote:
> On 9/29/05, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> > On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> >
> > > > > Number of Copies | Update perl Sec
> > > > >
> > > > > 1 -->
On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> > > Number of Copies | Update perl Sec
> > >
> > > 1 --> 119
> > > 2 ---> 59
> > > 3 ---> 38
> > > 4 ---> 28
> > > 5 --> 22
> > > 6 --> 19
> > > 7 --> 16
> > > 8 --> 14
> > > 9 --> 11
> > > 10 --> 11
> > > 11 --> 10
> >
> > So, 11 instances re
On Wed, 28 Sep 2005, Rajesh Kumar Mallah wrote:
> Hi
>
> While doing some stress testing for updates in a small sized table
> we found the following results. We are not too happy about the speed
> of the updates particularly at high concurrency (10 clients).
>
> Initially we get 119 updates / sec
On Sun, 11 Sep 2005, Mark Dilger wrote:
> All,
>
> In the psql output below, I would expect the second query to run faster,
> because the b-tree index on two columns knows the values of 'b' for any
> given value of 'a', and hence does not need to fetch a row from the
> actual table. I am not seei
On Wed, 24 Aug 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > A filesystem could, in theory, help us by providing an API which allows us
> > to tell the file system either: the way we'd like it to read ahead, the
> > fact that we don't
On Wed, 24 Aug 2005, PFC wrote:
>
> > Josh Berkus has already mentioned this as conventional wisdom as written
> > by Oracle. This may also be legacy wisdom. Oracle/Sybase/etc has been
> > around for a long time; it was probably a clear performance win way back
> > when. Nowadays with how far open
On Sat, 20 Aug 2005 ohp@pyrenet.fr wrote:
> Hi,
>
> While testing 8.1dev I came to this:
>
> CREATE TABLE t (
> a int,
> b int
> PRIMARY KEY (a,b));
>
> In that case, the index is as big as the table.
Right. Think about it: the index must store a, b, a reference to the data
in the table itself a
The query plan does *not* look okay.
> electric=# EXPLAIN ANALYZE
> electric-# SELECT datavalue, logfielddatatype, timestamp FROM logdata_recent
> electric-# WHERE (logfielddatatype = 70 OR logfielddatatype = 71 OR
> logfielddatatype = 69)
> electric-# AND graphtargetlog = 1327
> electric-# AND t
Hi Alan,
On Wed, 17 Aug 2005, Alan Stange wrote:
> Hello all,
>
> is there a simple way to limit the number of concurrent callers to a
> stored proc?
>
> The problem we have is about 50 clients come and perform the same
> operation at nearly the same time. Typically, this query takes a few
> sec
On Thu, 11 Aug 2005, Tino Wildenhain wrote:
> Am Donnerstag, den 11.08.2005, 00:40 -0400 schrieb Mark Cotner:
> > Here's a trigger I wrote to perform essentially the same purpose. The nice
> > thing about this is it keeps the number up to date for you, but you do incur
> > slight overhead.
> ...
Hi Dan,
On Wed, 10 Aug 2005, Dan Harris wrote:
> I have a web page for my customers that shows them count of records
> and some min/max date ranges in each table of a database, as this is
> how we bill them for service. They can log in and check the counts
> at any time. I'd like for the counts
zOn Thu, 28 Jul 2005, Matthew Schumacher wrote:
> Gavin Sherry wrote:
>
> >
> > I had a look at your data -- thanks.
> >
> > I have a question though: put_token() is invoked 120596 times in your
> > benchmark... for 616 messages. That's nearly 2
On Thu, 28 Jul 2005, Matthew Schumacher wrote:
> Karim Nassar wrote:
> > On Wed, 2005-07-27 at 14:35 -0800, Matthew Schumacher wrote:
> >
> >
> >>I put the rest of the schema up at
> >>http://www.aptalaska.net/~matt.s/bayes/bayes_pg.sql in case someone
> >>needs to see it too.
> >
> >
> > Do you h
Hi,
On Thu, 28 Jul 2005, Kari Lavikka wrote:
> ->8 Relevant rows from postgresql.conf 8<-
>
> shared_buffers = 15000 # min 16, at least max_connections*2, 8KB each
> work_mem = 1536 # min 64, size in KB
As an aside, I'd increase work_mem -
Hi Chris,
Have you considered breaking the data into multiple chunks and COPYing
each concurrently?
Also, have you ensured that your table isn't storing OIDs?
On Mon, 25 Jul 2005, Chris Isaacson wrote:
> #---
>
> # RESOURC
On Fri, 22 Apr 2005, Shoaib Burq (VPAC) wrote:
> Please see attached the output from explain analyse. This is with the
>
> shared_buffers = 10600
> work_mem = 102400
> enable_seqscan = true
>
> BTW I guess should mention that I am doing the select count(*) on a View.
>
> Ran the
On Thu, 21 Apr 2005, Jeff wrote:
>
> On Apr 21, 2005, at 7:49 AM, Shoaib Burq (VPAC) wrote:
>
> > Now I have not touch the $PGDATA/postgresql.conf (As I know very little
> > about memory tuning) Have run VACCUM & ANALYZE.
> >
> You should really, really bump up shared_buffers and given you have 8G
Hi,
On Mon, 4 Apr 2005, Steven Rosenstein wrote:
>
>
>
>
> Today while trying to do a bulk COPY of data into a table, the process
> aborted with the following error message:
>
> ERROR: end-of-copy marker corrupt
> CONTEXT: COPY tbl_logged_event, line 178519: "606447014,1492,2005-02-24
> 03:16:14,
On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote:
> I wonder if I would like to increase more RAM from 4 Gb. to 6 Gb. [which I
> hope
> to increase more performance ] and I now I used RH 9 and Pgsql 7.3.2 ON DUAL
> Xeon 3.0 server thay has the limtation of 4 Gb. ram, I should use which OS
> between F
On Wed, 12 Jan 2005 [EMAIL PROTECTED] wrote:
> I wonder if I would like to increase more RAM from 4 Gb. to 6 Gb. [which I
> hope
> to increase more performance ] and I now I used RH 9 and Pgsql 7.3.2 ON DUAL
> Xeon 3.0 server thay has the limtation of 4 Gb. ram, I should use which OS
> between F
On Tue, 4 Jan 2005 [EMAIL PROTECTED] wrote:
> Today is the first official day of this weeks and the system run better in
> serveral points but there are still some points that need to be corrected.
> Some
> queries or some tables are very slow. I think the queries inside the programe
> need to be
On Sat, 30 Oct 2004, Dustin Sallings wrote:
> > If the solution is to just write a little client that uses perl
> > DBI to fetch rows one at a time and write them out, that's doable,
> > but it would be nice if psql could be made to "just work" without
> > the monster RSS.
>
> It wouldn't
On Thu, 21 Oct 2004, Joshua Marsh wrote:
> Recently, we have found customers who are wanting to use our service
> with data files between 100 million and 300 million records. At that
> size, each of the three major tables will hold between 150 million and
> 700 million records. At this size, I c
On Fri, 15 Oct 2004, Bernd wrote:
> Hi,
>
> we are working on a product which was originally developed against an Oracle
> database and which should be changed to also work with postgres.
>
> Overall the changes we had to make are very small and we are very pleased with
> the good performance of p
On Thu, 6 May 2004, Shridhar Daithankar wrote:
> Richard Huxton wrote:
>
> > Christopher Kings-Lynne wrote:
> >
> What's the case of bigger database PostgreSQL (so greate and amount of
> registers) that they know???
> >> Didn't someone say that RedSheriff had a 10TB postgres database or
On Tue, 12 Aug 2003, Bruce Momjian wrote:
>
> I think Gavin Sherry is working on this. I am CC'ing him.
>
> ---
Yes I am working on this. I am about 50% of the way through the patch but
have been held u
38 matches
Mail list logo
