Charles Sprickman wrote:
Hello all,
It seems that I'm starting to outgrow our current Postgres setup. We've
been running a handful of machines as standalone db servers. This is
all in a colocation environment, so everything is stuffed into 1U
Supermicro boxes. Our standard build looks like
Charles,
> Lastly, one thing that I'm not yet finding in trying to
> educate myself on SANs is a good overview of what's come out
> in the past few years that's more affordable than the old
> big-iron stuff. For example I saw some brief info on this
> list's archives about the Dell/EMC offeri
Hello all,
It seems that I'm starting to outgrow our current Postgres setup. We've been
running a handful of machines as standalone db servers. This is all in a
colocation environment, so everything is stuffed into 1U Supermicro boxes. Our
standard build looks like this:
Supermicro 1U w/S
Simon,
> Yes, I'd expect something like this right now in 8.1; the
> numbers stack up to PostgreSQL doing equivalent join speeds,
> but w/o star join.
I do expect a significant improvement from 8.1 using the new bitmap index
because there is no need to scan the full Btree indexes. Also, the
On 12/14/05, Simon Riggs <[EMAIL PROTECTED]> wrote:
Maybe not for queries, but if you use a date range then you never needto run a DELETE and never need to VACUUM.You could split the data into two-day chunks.
That's an interesting idea, thanks.
> Am I using a horrid method for partitioning the data
On Thu, 2005-12-08 at 12:26 +0100, Pål Stenslet wrote:
> I'm currently benchmarking several RDBMSs with respect to analytical
> query performance on medium-sized multidimensional data sets. The data
> set contains 30,000,000 fact rows evenly distributed in a
> multidimensional space of 9 hierarchic
Postgres 8.1 performance rocks (compared with 8.0) specially with the use
in-memory index bitmaps. Complex queries that used to take 30+ minutes, it
takes now a few minutes to complete in 8.1. Many thanks to the all wonderful
developers for the huge 8.1 performance boost.
---
Husam Tomeh
On Mon, 2005-12-12 at 15:07 +1300, Mike C wrote:
> Partitioning on date range doesn't make much sense for this setup,
> where a typical 1-month query spans both tables (as the billing month
> for the customer might start midway through a calendar month).
Maybe not for queries, but if you use a da
On Tue, 2005-12-13 at 15:59 +, Richard Huxton wrote:
> Ключников А.С. wrote:
> > And
> > select * from base
> > where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
> > 10 seconds
> >
> > select * from base
> > where id in (select id from device where id = 1 or id = 2
Resending it here as it may be more relevant here...
Ameet
-- Forwarded message --
Date: Tue, 13 Dec 2005 11:24:26 -0600 (CST)
From: Ameet Kini <[EMAIL PROTECTED]>
To: pgsql-admin@postgresql.org
Subject: Lots of postmaster processes
In our installation of the postgres 7.4.7, w
* Richard Huxton [2005-12-13 15:59:11 +]:
> Ключников А.С. wrote:
> >And
> >select * from base
> > where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
> >10 seconds
> >
> >select * from base
> > where id in (select id from device where id = 1 or id = 2) and
> >
On Tue, Dec 13, 2005 at 06:18:19PM +0300, Ключников А.С. wrote:
> select * from base
> where id in (select id from device where id = 1 or id = 2) and
> datatime between '2005-05-15' and '2005-05-17';
> 10 minits
That's a really odd way of saying "1 or 2". It probably has to go through
Jim C. Nasby writes:
On Fri, Dec 02, 2005 at 06:28:09PM -0500, Francisco Reyes wrote:
I am in the process of designing a new system.
There will be a long list of words such as
-word table
word_id integer
word varchar
special boolean
Some "special" words are used to determine if some work is t
Ключников А.С. wrote:
And
select * from base
where id in (1,2) and datatime between '2005-05-15' and '2005-05-17';
10 seconds
select * from base
where id in (select id from device where id = 1 or id = 2) and
datatime between '2005-05-15' and '2005-05-17';
10 minits
Why?
Run
Hi.
create table device(id int);
insert into device values(1);
insert into device values(2);
.
insert into device values(250);
create table base (
id int,
data float,
datat
Yes, that's how I solved it... and I totally agree that it's hard for the
planner to guess what to do on the partitions. But maybe there should be
something in the docs explaining the limitations ...
I'm only asking for the biggest 100 ids from the table, so I thought maybe the
planner would ta
I just saw that there is no where clause in the query, that you had
fed to explain plan.
you need to include a where clause based on id_machine column to see the effect.
On 12/13/05, Pandurangan R S <[EMAIL PROTECTED]> wrote:
> Did you set constraint_exclusion = true in postgresql.conf file?
>
> O
Did you set constraint_exclusion = true in postgresql.conf file?
On 12/13/05, Marc Cousin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been working on trying to partition a big table (I've never partitioned a
> table in any other database till now).
> Everything went ok, except one query that didn't
Hi,
I've been working on trying to partition a big table (I've never partitioned a
table in any other database till now).
Everything went ok, except one query that didn't work afterwards.
I've put the partition description, indexes, etc ..., and the explain plan
attached.
The query is extremel
19 matches
Mail list logo
