Re: [PERFORM] Hosted servers with good DB disk performance?

Hi, Greg Smith writes: > I keep falling into situations where it would be nice to host a server > somewhere else. Virtual host solutions and the mysterious cloud are no good > for the ones I run into though, as disk performance is important for all the > applications I have to deal with. A fre

Re: [PERFORM] Bytea updation

ramasubramanian wrote: > How to insert or update a file in a table using the query in postgres > CREATE TABLE excel_file_upload > ( > user_id integer, > excel_file bytea > } > > example > insert into excel_file_upload values(1,file1) > > file1 can be any file *.doc,*.xls > How i ca

[PERFORM] L

ramasubramanian, 27.05.2009 08:42: How to insert or update a file in a table using the query in postgres CREATE TABLE excel_file_upload ( user_id integer, excel_file bytea } example insert into excel_file_upload values(1,file1) file1 can be any file *.doc,*.xls How i can do this(with

[PERFORM] running bonnie++

Hey folks, During Greg Smith's lecture last week I could have sworn I saw on the screen at some point a really long command line for bonnie++ - with all the switches he uses. But checking his slides I don't see this. Am I mis-remembering? Can someone recommend the best way to run it? What comb

Re: [PERFORM] running bonnie++

You should be able to get a good idea of the options from "man bonnie++". I've always just used the defaults with bonnie++ Also, you'll find Gregs older notes are here http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm --- On Wed, 27/5/09, Alan McKay wrote: > From: Alan McK

Re: [PERFORM] Hosted servers with good DB disk performance?

On Tue, 2009-05-26 at 19:52 -0600, Scott Marlowe wrote: > On Tue, May 26, 2009 at 7:41 PM, Scott Carey wrote: > > > > On 5/26/09 6:17 PM, "Greg Smith" wrote: > > > >> On Tue, 26 May 2009, Joshua D. Drake wrote: > >> > >>> CMD doesn't rent hardware you would have to provide that, Rack Space > >>>

[PERFORM] Improve Query

So Google hasn't been helpful and I'm not entirely sure what to look for in the mailing lists to find the answer to my problem, so here goes. I have a query and I have run explain analyze select count(*) from score where leaderboardid=35 and score <= 6841 and active The result is "Aggregate (co

Re: [PERFORM] Improve Query

try creating index on all three columns. Btw, 38ms is pretty fast. If you run that query very often, do prepare it, cos I reckon it takes few ms to actually create plan for it. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Hosted servers with good DB disk performance?

Heh. Well on another consideration any "rental" will out live its cost effectiveness in 6 months or less. At least if you own the box, its useful for a long period of time. Heck I got a quad opteron, 2 gig of memory with 2 6402 HP controllers and 2 fully loaded MSA30s for 3k. Used of course but

Re: [PERFORM] running bonnie++

On Wed, 27 May 2009, Alan McKay wrote: During Greg Smith's lecture last week I could have sworn I saw on the screen at some point a really long command line for bonnie++ - with all the switches he uses. You're probably thinking of the one I showed for sysbench, showing how to use it to run a

Re: [PERFORM] Hosted servers with good DB disk performance?

On Tue, May 26, 2009 at 7:58 PM, Dave Page wrote: > On 5/26/09, Greg Smith wrote: > > I keep falling into situations where it would be nice to host a server > > somewhere else. Virtual host solutions and the mysterious cloud are no > > good for the ones I run into though, as disk performance is

Re: [PERFORM] Improve Query

The plan ought to be different when there are more scores and the table is analyzed and your statistics target is high enough. At this point you don't have enough data to merit doing anything but a seq scan. The overhead is simply not worth it. You could try inserting a lot more rows. I'd creat

Re: [PERFORM] Improve Query

I'm running the inserts now via a JDBC call I have, which is then followed up by the query I'm showing and a few others. I have run tests on all of the others, and all others run index scans and are very fast, 10 ms or less. This one started at 2 milliseconds when the table is empty and is up to

Re: [PERFORM] Improve Query

you have to vacuum analyze after you've created index, afaik. No, count(*) is still counting rows. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Improve Query

Still getting a seq scan after doing vacuum analyze. Any other ideas? 2009/5/27 Grzegorz Jaśkiewicz : > you have to vacuum analyze after you've created index, afaik. > No, count(*) is still counting rows. > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make ch

Re: [PERFORM] Improve Query

Zach Calvert wrote: Still getting a seq scan after doing vacuum analyze. Any other ideas? Try CLUSTERing the table on the (leaderboardid, active, score) index. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-performance mailing list (pgsql-performance@p

[PERFORM] Postgres Clustering

Hey folks, I have done some googling and found a few things on the matter. But am looking for some suggestions from the experts out there. Got any good pointers for reading material to help me get up to speed on PostgreSQL clustering? What options are available? What are the issues? Terminol

Re: [PERFORM] Postgres Clustering

Alan McKay wrote on 27.05.2009 19:57: > What options are available? I guess a good starting point is the Postgres Wiki: http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make chan

Re: [PERFORM] Postgres Clustering

On Wed, May 27, 2009 at 1:57 PM, Alan McKay wrote: > Hey folks, > > I have done some googling and found a few things on the matter. But > am looking for some suggestions from the experts out there. > > Got any good pointers for reading material to help me get up to speed > on PostgreSQL clusteri

Re: [PERFORM] Postgres Clustering

Alan, here I'm implementing something similar to the Chord protocol [1] on the application level to partition my data across 6 PostgreSQL servers with N+1 replication. Two up sides on this approch: 1 - When one server is down the load is spread between all the other ones, instead of going only to

Re: [PERFORM] Postgres Clustering

Try Cybercluster -Mensaje original- De: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] En nombre de Alan McKay Enviado el: miércoles, 27 de mayo de 2009 13:57 Para: pgsql-performance@postgresql.org; pgsql-gene...@postgresql.org Asunto: [PERFORM]

Re: [PERFORM] Postgres Clustering

Hi, Le 27 mai 09 à 19:57, Alan McKay a écrit : I have done some googling and found a few things on the matter. But am looking for some suggestions from the experts out there. Got any good pointers for reading material to help me get up to speed on PostgreSQL clustering? What options are avai

Re: [PERFORM] Postgres Clustering

> Depending on your exact needs, which the terminology you're using only allow > to guess about, you might enjoy this reading: >  http://wiki.postgresql.org/wiki/Image:Moskva_DB_Tools.v3.pdf Thanks. To be honest I don't even know myself what my needs are yet. I've only been on the job here for a