On Sat, Oct 01, 2005 at 02:00:12PM -0400, Tom Lane wrote:
I wrote:
It's presumably mostly in the pg_table_is_visible() calls.
I did some profiling on a test case with 1 tables, and noticed that
a big part of the problem is that the catalog caches become entirely
useless: almost every
I wrote:
It's presumably mostly in the pg_table_is_visible() calls.
I did some profiling on a test case with 1 tables, and noticed that
a big part of the problem is that the catalog caches become entirely
useless: almost every catcache lookup ends up going to the underlying
tables. This is
On Wed, Sep 28, 2005 at 11:35:31AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Sorry, remembered it wrong. It's 'Did not find any relation named',
which appears to be in bin/psql/describe.c. It does occur when trying to
do a \d on a specific table.
Hmm, no immediate
On Fri, 30 Sep 2005, Jim C. Nasby wrote:
ERROR: cache lookup failed for relation 1906465919
It is on an exact table name. When we retry the describe on a failure,
sometimes it works and sometimes it fails again. When it fails again
the relation number is different. Also, \d schema.table
Jim C. Nasby [EMAIL PROTECTED] writes:
Sorry, remembered it wrong. It's 'Did not find any relation named',
which appears to be in bin/psql/describe.c. It does occur when trying to
do a \d on a specific table.
Hmm, no immediate ideas. You haven't provided a lot of context about
this --- when
On Mon, Sep 26, 2005 at 03:00:44PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
It's presumably mostly in the pg_table_is_visible()
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Sep 26, 2005 at 03:00:44PM -0400, Tom Lane wrote:
It's presumably mostly in the pg_table_is_visible() calls. Not sure if
we can do much to speed those up, but: how many schemas in your search
path? What's the distribution of pg_class entries
On Tue, Sep 27, 2005 at 06:53:13PM -0400, Tom Lane wrote:
Also, do you have any idea on the 'Did not find relation named
table-thats-there' error? table-thats-there isn't a temp table, and I
don't
believe they're even using temp tables, so I don't think that's the issue.
Uh, what's the
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
Also, not sure if this matters, but they're occasionally getting errors
like 'Did not find relation named table that exists' (where 'table
that exists' is the name of some table that is in the catalog) from \d.
Does anyone know
On Sun, Sep 25, 2005 at 10:10:22AM +0300, Hannu Krosing wrote:
On L, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c
Jim C. Nasby [EMAIL PROTECTED] writes:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
It's presumably mostly in the pg_table_is_visible() calls. Not sure if
we can do much to speed those up, but: how
On L, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c (cost=0.00..2343.09 rows=6124 width=73)
(actual
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c (cost=0.00..2343.09 rows=6124 width=73) (actual
time=0.325..22100.840 rows=16856 loops=1)
Filter: (((relkind =
On Sat, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c (cost=0.00..2343.09 rows=6124 width=73)
(actual
On Sat, Sep 24, 2005 at 08:20:47PM -0400, Rod Taylor wrote:
On Sat, 2005-09-24 at 18:59 -0500, Jim C. Nasby wrote:
I have a client with a database that contains 4000 relations according
to vacuum verbose, and \d in psql is painfully slow. In particular...
- Seq Scan on pg_class c
15 matches
Mail list logo
