Fredrik Bertilsson escribió:
> Hi,
> we are using Postgres on both Solaris servers and Linux servers, and
> Postgres are much slower on Solaris servers. We have tested with different
> versions of Solaris and Postgres, but the fact remains: Postgres seems to be
> much faster on Linux server. Does a
Jozsef Szalay escribió:
> I don't know why ANALYZE would have any effect on a sequential scan of a
> table but it does appear to impact both performance and memory usage
> significantly.
It doesn't. What it does is provide the query optimizer with the
information that it needs to know that the t
On 8/11/07, Detlef Rudolph <[EMAIL PROTECTED]> wrote:
> Hello Group,
>
> I've tried the VACUUM ANALYSE, that doesn't help
> much, but VACUUM FULL improves Performance down
> from about 40 secs to 8.
If vacuum full fixes a performance problem, then you have a regular
vacuum problem of some sort.
M
On 8/16/07, Robert D Oden <[EMAIL PROTECTED]> wrote:
> After reading many articles which indicate the more disk spindles the
> better performance and separating indexes, WAL and data on different
> sets of spindles, I've come up with a couple of questions.
>
> We am planning to buy an external raid
Hello All.
I have a table with ca. 100.000.000 records. The main idea is make
Partitioning for this table (1000 or 1 tables).
Let's take for example.
CREATE TABLE test
(
id integer,
data date not null default now()
)
WITHOUT OIDS;
CREATE TABLE test00 ( CHECK ( id%100 = 0 ) ) INHERITS (te
Hi,
we are using Postgres on both Solaris servers and Linux servers, and
Postgres are much slower on Solaris servers. We have tested with different
versions of Solaris and Postgres, but the fact remains: Postgres seems to be
much faster on Linux server. Does anybody else has the same experience?
B
After reading many articles which indicate the more disk spindles the
better performance and separating indexes, WAL and data on different
sets of spindles, I've come up with a couple of questions.
We am planning to buy an external raid sub-system utilizing raid 10. The
sub-system will consist
Hello Group,
I've tried the VACUUM ANALYSE, that doesn't help
much, but VACUUM FULL improves Performance down
from about 40 secs to 8. I think in future I would
use the reltuples value from pg_class for the table.
Thanks a lot for your answers and a good Sunday,
Det
---(
I'm have the following view as part of a larger, aggregate query that is
running slower than I'd like. There are 4 views total, each very
similar to this one. Each of the views is then left joined with data
from some other tables to give me the final result that I'm looking for.
I'm hoping that
Hello!
Here's my test database:
# table
CREATE TABLE public.t
(
id integer NOT NULL,
a integer NOT NULL,
CONSTRAINT pk_t PRIMARY KEY (id)
)
CREATE INDEX idx_t_a
ON public.t
USING btree
(a);
# function
CREATE OR REPLACE FUNCTION public.f()
RETURNS integer AS
$BODY$BEGIN
RET
With the limited time I had, I could not produce a test case that I
could have submitted to this forum.
I have found another issue in production though. In addition to the
SELECT COUNT(*) FROM table;
taking forever (>6 hours on a table with 100,000 rows and with no
indexes on a system with Li
I originally posted the question below back in Dec 2006, and many
helpful suggestions resulted. Unfortunately, since this was a closet
effort, my official duties pushed further exploration to the back
burner, then I lost my original test environment. So while I can no
longer compare to BigDBM
On Aug 17, 2007, at 5:23 PM, Michael Stone wrote:
On Fri, Aug 17, 2007 at 10:43:18AM +0200, Frank Schoep wrote:
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
(cost=0.00..37612.76 rows=14221 width=48) (actual
time=0.125..13.686 rows=2000 loops=1)
[snip]
I'm not an expert at h
On Fri, Aug 17, 2007 at 10:43:18AM +0200, Frank Schoep wrote:
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
(cost=0.00..37612.76 rows=14221 width=48) (actual time=0.125..13.686
rows=2000 loops=1)
[snip]
I'm not an expert at how the planner decides which query plan to use,
N
On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote:
…
try to change the query to:
SELECT * FROM movies WHERE letter = 'T' ORDER BY letter ASC, name
ASC LIMIT 100
OFFSET 1900;
Thanks for the suggestion, however executing this query takes even
longer regardless of work_mem. The que
On Thu, Aug 16, 2007 at 06:14:02PM +0200, Frank Schoep wrote:
> The (example) query:
> SELECT * FROM movies WHERE letter = 'T' ORDER BY name ASC LIMIT 100
> OFFSET 1900;
try to change the query to:
SELECT * FROM movies WHERE letter = 'T' ORDER BY letter ASC, name ASC LIMIT 100
OFFSET 1900;
d
16 matches
Mail list logo
