> The most significant impact is that it takes up twice as much space,
> including the primary key index. This means fewer entries per block,
> which means slower scans and/or more blocks to navigate through. Still,
> compared to the rest of the overhead of an index row or a table row, it
> is low
Scott Carey writes:
> I've got 200,000 tables in one db (8.4), and some tools barely work. The
> system catalogs get inefficient when large and psql especially has trouble.
> Tab completion takes forever, even if I make a schema "s" with one table in
> it and type "s." and try and tab complete --
On 10/9/09 2:02 PM, "Merlin Moncure" wrote:
> On Fri, Oct 9, 2009 at 1:46 PM, Scott Otis wrote:
>> Over the next couple of months we will be creating an instance of our
>> solution for each public school district in the US which is around 18,000.
>> That means currently we would be creating
>
>> any thoughts here? recommendations on what to do with a tight budget?
>> It could be the answer is that I just have to go back to the bean
>> counters and tell them we have no choice but to start spending some
>> real money. But on what? And how do I prove that this is the only
>> choice
On Fri, Oct 9, 2009 at 9:45 AM, Alan McKay wrote:
> We've just discovered thanks to a new Munin plugin
> http://blogs.amd.co.at/robe/2008/12/graphing-linux-disk-io-statistics-with-munin.html
> that our production DB is completely maxing out in I/O for about a 3
> hour stretch from 6am til 9am
> Th
On Fri, Oct 9, 2009 at 1:46 PM, Scott Otis wrote:
> Over the next couple of months we will be creating an instance of our
> solution for each public school district in the US which is around 18,000.
> That means currently we would be creating 18,000 databases (all on one server
> right now – w
On Fri, Oct 9, 2009 at 10:45 AM, Alan McKay wrote:
> Hey folks,
>
> CentOS / PostgreSQL shop over here.
>
> I'm hitting 3 of my favorite lists with this, so here's hoping that
> the BCC trick is the right way to do it :-)
I added pgsql-performance back in in my reply so we can share with the
rest
- "Alan McKay" escreveu:
> CentOS / PostgreSQL shop over here.
>
> Our system
> IBM 3650 - quad 2Ghz e5405 Xeon
> 8K SAS RAID Controller
> 6 x 300G 15K/RPM SAS Drives
> /dev/sda - 2 drives configured as a RAID 1 for 300G for the OS
> /dev/sdb - 3 drives configured as RAID5 for 600G for the DB
On 10/09/2009 12:56 PM, tsuraan wrote:
I have a system where it would be very useful for the primary keys for
a few tables to be UUIDs (actually MD5s of files, but UUID seems to be
the best 128-bit type available). What is the expected performance of
using a UUID as a primary key which will have
Scott Otis wrote:
I am seeking advice on what the best setup for the following would be.
My company provides a hosted web calendaring solution for school
districts. For each school district we have a separate database.
Each database has 57 tables.
Over the next couple of months
I am seeking advice on what the best setup for the following would be.
My company provides a hosted web calendaring solution for school
districts. For each school district we have a separate database. Each
database has 57 tables. There are a total of 649 fields in those
tables. Here is a ta
More update
If I run the concurrent re index locally (psql session) it works fine, but
when run via a connection through php I get the error
Can't be slon, since I can do this locally, but why would postgres have an
issue with a remote connection?
the basic script:
$connectString = "host=serve
I have a system where it would be very useful for the primary keys for
a few tables to be UUIDs (actually MD5s of files, but UUID seems to be
the best 128-bit type available). What is the expected performance of
using a UUID as a primary key which will have numerous foreign
references to it, versu
Hey folks,
CentOS / PostgreSQL shop over here.
I'm hitting 3 of my favorite lists with this, so here's hoping that
the BCC trick is the right way to do it :-)
We've just discovered thanks to a new Munin plugin
http://blogs.amd.co.at/robe/2008/12/graphing-linux-disk-io-statistics-with-munin.html
On Fri, Oct 9, 2009 at 3:11 AM, Shiva Raman wrote:
> Dear all
> with reference to the discussions and valuable suggestions i got from the
> list, the code has been reviewed and updated with explicit commit . There is
> a good improvement in performance .I am also planning to upgrade the
> datab
On Fri, Oct 09, 2009 at 08:31:54PM +0800, Xia Qingran wrote:
> On Mon, Oct 5, 2009 at 9:58 AM, Omar Kilani wrote:
> > Hi Xia,
> >
> > Try this patch:
> >
> > http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
> >
> > It's a hack, but it works for us. I think you're probably spending
> >
On Mon, Oct 5, 2009 at 9:58 AM, Omar Kilani wrote:
> Hi Xia,
>
> Try this patch:
>
> http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch
>
> It's a hack, but it works for us. I think you're probably spending
> most of your query time planning, and this patch helps speed things up
> 10x o
You should also keep in mind that JDBC uses prepared statements, so you have
to explain analyze accordingly.
Dave
On Thu, Oct 8, 2009 at 5:18 PM, Tom Lane wrote:
> G B writes:
> > How can explain-analyze return significantly much faster than other
> means?
>
> If the returned data is large or
Dear all
with reference to the discussions and valuable suggestions i got from the
list, the code has been reviewed and updated with explicit commit . There is
a good improvement in performance .I am also planning to upgrade the
database from 8.1 to 8.3 /8.4 .
My current OS is SLES 10 SP3 def
19 matches
Mail list logo
