Re: [PERFORM] Multiple Uniques

Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: How many cycles are we really talking about, though? I have a patch which I'll send along in a few days which implements a similar optimization: if a subselect is referenced by EXISTS or IN, we can discard

[PERFORM] Question on Byte Sizes

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

[PERFORM] Interesting performance behaviour

#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

Re: [PERFORM] Interesting performance behaviour

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 plan)

[PERFORM] effective_cache_size in 7.3.4?

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

Re: [PERFORM] Interesting performance behaviour

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 machine with

Fwd: [PERFORM] Interesting performance behaviour

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 LIMIT 1

Re: [PERFORM] Equivalent praxis to CLUSTERED INDEX?

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,