[PERFORM] Two "equivalent" WITH RECURSIVE queries, one of them slow.

Hello. I have a tree-like table with a three-field PK (name, date, id) and one parent field. It has 5k to 6k records as of now, but it will hold about 1 million records. I am trying the following WITH RECURSIVE query: WITH RECURSIVE t AS ( SELECT par.id AS tid, par.name, p

Re: [PERFORM] Slow queries from information schema

On Sat, 2009-02-14 at 15:02 -0500, Tom Lane wrote: > Octavio Alvarez writes: > > The result, on the above view: ~80ms. Fair enough. But if I apply a > > condition: > > SELECT * FROM ___pgnui_relation_tree.raw_relation_tree WHERE > > parent_schema <> child_schem

[PERFORM] Slow queries from information schema

I'm aware you already know that information_schema is slow [1] [2], so I just want to expose/document another case and tests I did. I'm using the following view to check what tables depend on what other tables. CREATE VIEW raw_relation_tree AS SELECT tc_p.table_catalog AS parent_catalog, tc

[PERFORM] Sorting when LEFT JOINING to 2 same tables, even aliased.

377 loops=3473) -> Seq Scan on t_materias t_materias__equivalentes (cost=0.00..8.77 rows=377 width=22) (actual time=0.000..1.000 rows=377 loops=1) -> Hash (cost=2.07..2.07 rows=107 width=13) (actual time=0.000..0.000 rows=0 loops=1) -> Seq Scan on t_grupos (cost=0.00..2.07 rows=107 width=13) (actual time=0

Re: [PERFORM] Seq scan on zero-parameters function

Tomasz Myrta said: > Dnia 2004-02-06 08:19, U¿ytkownik Octavio Alvarez napisa³: >> In each couple, the first one has a WHERE field = function() >> condition, just like the second one, but in the form WHERE field = >> (SELECT function()). In my opinion, both should have the s

[PERFORM] Seq scan on zero-parameters function

nu, compiled by GCC 2.96 (1 row) -- Octavio Alvarez. E-mail: [EMAIL PROTECTED] Agradezco que sus correos sean enviados siempre a esta dirección. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nom

Re: [PERFORM] Slow delete times??

I checked datatype mismatches, and there are none. All my FKs are integers, like the referenced column of the referenced table. I was thinking on dropping the indexes before doing the deletes, but Joshua suggested using TRUNCATE instead. Thanks. Octavio. Tom Lane said: > "Octavio Alvarez&

[PERFORM] Slow delete times??

and is a Celeron 433 MHz. It still has enough disk space, I think: about 200 MB. * Disk is 4 MB. I guess it must be about what, 4500 RPM? * fsync is disabled. I don't know what other info to provide... Thanks in advance. -- Octavio Alvarez Piza. E-mail: [EMAIL PROTECTED] --