Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
although MS-SQL return result in 0.02 sec every time.
My server is a DELL PowerEdge 2600 with bi-processor Xeon a
Am 23.01.2007 um 11:34 schrieb Laurent Manchon:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this
query below
on a table with 80 rows:
select count(*)from tbl;
count(*) is doing a full tablescan over all your 80 rows. This is
a well known "feature"
of postgre
am Tue, dem 23.01.2007, um 11:34:52 +0100 mailte Laurent Manchon folgendes:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
If i remember correctly, i saw this question yesterday on an other
list..
On Tue, Jan 23, 2007 at 11:34:52AM +0100, Laurent Manchon wrote:
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
Contrary to your expectations, this is _not_ a query you'd expect to be fast
in Postgres. Try
On Tue, Jan 23, 2007 at 11:55:41AM +0100, Steinar H. Gunderson wrote:
> you'll find them to be much master.
s/master/faster/
/* Steinar */
--
Homepage: http://www.sesse.net/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will i
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
although MS-SQL return result in 0.02 sec every time.
My server is a DELL PowerEdge 2600 with bi-processor Xeon a
am Tue, dem 23.01.2007, um 13:34:19 +0100 mailte Laurent Manchon folgendes:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
PLEASE READ THE ANSWERS FOR YOUR OTHER MAILS.
Andreas
--
Andreas Krets
Does anyone have experience with using postgres for data warehousing?
Right, I saw one post suggestion to use mysql for a mostly read-only
database ... but anyway, I think it's not a question to change the
database platform for this project, at least not today ;-)
Ralph Kimball seems to be some ki
On 1/23/07, Tobias Brox <[EMAIL PROTECTED]> wrote:
Ralph Kimball seems to be some kind of guru on data warehousing, and
in his books he's strongly recommending to have a date dimension -
simply a table describing all dates in the system, and having
I would tend to agree with this line of thou
[Chad Wagner - Tue at 08:24:34AM -0500]
> I guess go with your gut, but at some point the expressions are going to be
> too complicated to maintain, and inefficient.
The layout of my system is quite flexible, so it should eventually be
fairly trivial to throw in a date dimension at a later stage.
In response to Laurent Manchon <[EMAIL PROTECTED]>:
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
>
> PostgreSQL return result in 28 sec every time.
> although MS-SQL return result in 0.02 sec every tim
At 07:34 AM 1/23/2007, Laurent Manchon wrote:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
1= Upgrade to the latest stable version of pg. That would be
8.2.x You are very much in the Dark Ages pg version wise.
pg 8.x has sign
Hello all,
I have a setup in which four client machines access
a Postgres database (8.1.1) (on a Linux box). So,
there are connections from each machine to the
database; hence, the Linux box has about 2 postgres
processes associated with each machine.
I am using the JDBC driver
(postgresql-8.
On 1/23/07, Tobias Brox <[EMAIL PROTECTED]> wrote:
Does anyone have experience with using postgres for data warehousing?
Right, I saw one post suggestion to use mysql for a mostly read-only
database ... but anyway, I think it's not a question to change the
database platform for this project, at l
On Tue, Jan 23, 2007 at 11:34:52 +0100,
Laurent Manchon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a slow response of my PostgreSQL database 7.4 using this query below
> on a table with 80 rows:
>
> select count(*)from tbl;
>
> PostgreSQL return result in 28 sec every time.
> although MS-
Hello,
I discovered a query which is taking 70 seconds on 8.2.1 which used to take
under a second on 8.1.2. I was digging into what was causing it and I
believe the problem is a view which the planner estimates will return 1 row
when it actually returns 3500. When I join with the view, the plann
Laurent Manchon wrote:
Hi,
I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:
select count(*)from tbl;
PostgreSQL return result in 28 sec every time.
Can you post the results of:
analyze verbose tbl;
explain analyze select count(*) from
Tobias Brox wrote:
I suppose the strongest argument for introducing date dimensions already
now is that I probably will benefit from having conform and
well-designed dimensions when I will be introducing more data marts. As
for now I have only one fact table and some few dimensions in the
syst
Hi,
For I can not find too much information about how to use vacuum, I want
to ask some general information about the guideline of vacuum planning.
1. How do we know if autovacuum is enough for my application, or should
I setup a vacuum manually from cron for my application?
2. How to set t
"Dave Dutcher" <[EMAIL PROTECTED]> writes:
> I discovered a query which is taking 70 seconds on 8.2.1 which used to take
> under a second on 8.1.2. I was digging into what was causing it and I
> believe the problem is a view which the planner estimates will return 1 row
> when it actually returns
Just have one example here:
workload: run pgbench in 365x24x7
database size: 100GB
the workload distribution:
06:00-24:00 100tps
00:00-06:00 20tps
how should we plan vacuum for this situation to get the highest performance?
Best regards
Galy
Galy Lee wrote:
> Hi,
>
> For I can no
21 matches
Mail list logo
