Re: [PERFORM] cpu_tuple_cost

On Thu, Mar 17, 2005 at 09:54:29AM -0800, Josh Berkus wrote: > > > Yes it is.  I ran experiments back in the late 90s to derive it. > > Check the archives. > > H ... which list? These look like relevant threads: http://archives.postgresql.org/pgsql-hackers/2000-01/msg00910.php http://archiv

Re: [PERFORM] multi-column index

Manfred Koizar <[EMAIL PROTECTED]> writes: > On Wed, 16 Mar 2005 22:19:13 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >> calculate the correlation explicitly for each index > May be it's time to revisit an old proposal that has failed to catch > anybody's attention during the 7.4 beta period: > htt

Re: [PERFORM] cpu_tuple_cost

Josh Berkus writes: >> Yes it is.  I ran experiments back in the late 90s to derive it. >> Check the archives. > H ... which list? -hackers, no doubt. -performance didn't exist then. regards, tom lane ---(end of broadcast)---

Re: [PERFORM] cpu_tuple_cost

Tom, > Yes it is. ÂI ran experiments back in the late 90s to derive it. > Check the archives. H ... which list? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EM

Re: [PERFORM] TOP 10 SQL commands and more

Ales, > is there some utilities for PG for tunnig database performance. To see > top 10 sql commands and so? Look up "PQA" on www.pgFoundry.org -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off

RES: [PERFORM] Help to find out problem with joined tables

Hi, Thanks for your reply. I have made this test without any user connect and after vacuum and all index recteated and tables analyzed. Well, produt.codpro is SERIAL And movest.codpro is NUMBER(8) Thanks Rodrigo -Mensagem original- De: Michael Fuhr [mailto:[EMAIL PROTECTED] Enviada

Re: [PERFORM] Building a DB with performance in mind

Alexander Ranaldi wrote: Greetings everyone, I am about to migrate to Postgres from MySQL. My DB isn't enormous (< 1gb), consists mostly of just text, but is accessed quite heavily. Because size isn't a huge issue, but performance is, I am willing to normalize as necessary. Currently I have a table

Re: [PERFORM] Building a DB with performance in mind

On Thu, Mar 17, 2005 at 10:56:10AM -0500, Alexander Ranaldi wrote: > Most of my queries return rows based on UserID, and also only if > Private is FALSE. Would it be in the interest of best performance to > split this table into two tables: "EntriesPrivate", > "EntriesNotPrivate" and remove the "Pr

[PERFORM] Building a DB with performance in mind

Greetings everyone, I am about to migrate to Postgres from MySQL. My DB isn't enormous (< 1gb), consists mostly of just text, but is accessed quite heavily. Because size isn't a huge issue, but performance is, I am willing to normalize as necessary. Currently I have a table "Entries" containing 5

[PERFORM] queries on huge tables

Title: Melding Hello all.   I am having a couple of tables with couple of hundre millions records in them. The tables contains a timestamp column. I am almost always interested in getting datas from a specific day or month. Each day contains aprox. 400.000 entries.   When I do such querie

[PERFORM] TOP 10 SQL commands and more

Hi, is there some utilities for PG for tunnig database performance. To see top 10 sql commands and so? Thank you a lot. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatyp

[PERFORM] 2 rows expected on a primary key

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm running a 7.4.x engine and I'm seeing in a explain analyze: - -> Hash (cost=4.00..4.00 rows=2 width=16) (actual time=30.542..30.542 rows=0 loops=1) -> Index Scan using user_login_login_key on user_login ul (cost=0.00..4.00 rows

Re: [PERFORM] multi-column index

On Thu, 17 Mar 2005 16:55:15 +0800, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: >Make it deal with cross-table fk correlations as well :) That's a different story. I guess it boils down to cross-column statistics for a single table. Part of this is the correlation between values in two or

Re: [PERFORM] multi-column index

May be it's time to revisit an old proposal that has failed to catch anybody's attention during the 7.4 beta period: http://archives.postgresql.org/pgsql-hackers/2003-08/msg00937.php I'm not sure I'd store index correlation in a separate table today. You've invented something better for functional

Re: [PERFORM] multi-column index

On Wed, 16 Mar 2005 22:19:13 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >calculate the correlation explicitly for each index May be it's time to revisit an old proposal that has failed to catch anybody's attention during the 7.4 beta period: http://archives.postgresql.org/pgsql-hackers/2003-08/msg

Re: [PERFORM] cpu_tuple_cost

On Mon, 14 Mar 2005 21:23:29 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > I think that the "reduce random_page_cost" mantra >is not an indication that that parameter is wrong, but that the >cost models it feeds into need more work. One of these areas is the cost interpolation depending on correlat

Re: [PERFORM] index scan on =, but not < ?

On Thu, 10 Mar 2005 10:24:46 +1000, David Brown <[EMAIL PROTECTED]> wrote: >What concerns me is that this all depends on the correlation factor, and >I suspect that the planner is not giving enough weight to this. The planner does the right thing for correlations very close to 1 (and -1) and for