On Tue, 2004-09-07 at 22:32, Jeremy M. Guthrie wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have a problem where I have the table format listed below. I have the
> primary key tsyslog_id and the index built against it. However, when I
> select a unique row, it will only ever
Mischa Sandberg wrote:
Coming from the MSSQL world, I'm used to the first step in optimization
to be, choose your clustered index and choose it well.
I see that PG has a one-shot CLUSTER command, but doesn't support
continuously-updated clustered indexes.
What I infer from newsgroup browsing is, su
by the way, this reminds me: I just ran a performance study at a company doing
an oracle-to-postgres conversion, and FYI converting from numeric and decimal
to integer/bigint/real saved roughly 3x on space and 2x on performance.
Obviously, YMMV.
adam
Tom Lane wrote:
Marc Cousin <[EMAIL PRO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a problem where I have the table format listed below. I have the
primary key tsyslog_id and the index built against it. However, when I
select a unique row, it will only ever do a seq scan even after I turn off
all other types except indexs
Joey Smith <[EMAIL PROTECTED]> writes:
> EXPLAIN ANALYZE SELECT message_idnr FROM messages WHERE mailbox_idnr
> = 1746::bigint AND status<2::smallint AND seen_flag = 0 AND unique_id
> != '' ORDER BY message_idnr ASC LIMIT 1;
> QUERY P
Otis,
> I saw a few mentions of 'effective_cache_size' parameter. Is this a
> new PG 7.4 option? I have PG 7.3.4 and didn't see that parameter in my
> postgresql.conf.
Nope. AFAIK, it's been around since 7.0.Maybe you accidentally cut it out
of your postgresql.conf?
--
--Josh
Josh Berk
Accidentally sent directly to Josh.
-- Forwarded message --
From: Joey Smith <[EMAIL PROTECTED]>
Date: Fri, 10 Sep 2004 15:57:49 -0600
Subject: Re: [PERFORM] Interesting performance behaviour
To: [EMAIL PROTECTED]
> > I see a similar speedup (and change in query plan) using "LIMI
> > shared_buffers = 1000
> > sort_mem = 1024
> > effective_cache_size = 1000
>
> effective_cache_size should be much higher, like 3/4 of your available RAM.
> This is probably the essence of your planner problem; the planner thinks you
> have no RAM.
I set effective_cache_size to 64000 on a mach
Hello,
I saw a few mentions of 'effective_cache_size' parameter. Is this a
new PG 7.4 option? I have PG 7.3.4 and didn't see that parameter in my
postgresql.conf.
Thanks,
Otis
---(end of broadcast)---
TIP 9: the planner will ignore your desire t
Joey,
> shared_buffers = 1000
> sort_mem = 1024
> effective_cache_size = 1000
effective_cache_size should be much higher, like 3/4 of your available RAM.
This is probably the essence of your planner problem; the planner thinks you
have no RAM.
> I see a similar speedup (and change in query pl
#postgresql on Freenode recommended I post this here.
I'm seeing some odd behaviour with LIMIT. The query plans are included
here, as are the applicable table and index definitions. All table,
index, and query information can be found in a standard dbmail 1.2.6
install, if anyone wants to try sett
Hello,
* I need information on the size of pg ARRAY[]'s :
I did not find any info in the Docs on this.
How many bytes does an array take on disk ?
Is there a difference between an array of fixed size elements like
integers, and an array of variable length elements like text ? is there a
pointe
12 matches
Mail list logo
