[GENERAL] Re: psql error: psql: symbol lookup error: psql: undefined symbol: PQconnectdbParams
Tanks a lot to all... Finally i got the solution... my postgres working fine on server... - Regards, Suresh Hosur -- View this message in context: http://postgresql.1045698.n5.nabble.com/psql-error-psql-symbol-lookup-error-psql-undefined-symbol-PQconnectdbParams-tp5104950p5107139.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Refine Form of My querry
Hi every1 how are u all??? Members i am new in postgres and want to work on pgrouting but i am facing some issue with it. Will u please help me??? I have loaded my line shapefile in pgadmin environment, which creates a table name 'Route', but when i made a query 'Create View' at it, it will show an error that "Relation 'Route' doesn't exist". can any1 explains me what this error means?? and how can i remove this error?? I am sending my problems with attachment please have a look at this.. With best regards Saqib Kazmi This message was sent using IMP, the Internet Messaging Program. - Attachments (Links will expire on 07/01/12) http://webmail.igis.nust.edu.pk/imp/attachment.php?u=saqib11%40igis.nust.edu.pk&t=1325171483&f=Route+Table+Error.docx -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Refine Form of My querry
On 12/29/11 2:11 AM, saqi...@igis.nust.edu.pk wrote: I am sending my problems with attachment please have a look at this.. please don't send attachments to email lists. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Refine Form of My querry
At 11:11 29/12/2011, you wrote: Hi every1 how are u all??? Members i am new in postgres and want to work on pgrouting but i am facing some issue with it. Will u please help me??? I have loaded my line shapefile in pgadmin environment, which creates a table name 'Route', but when i made a query 'Create View' at it, it will show an error that "Relation 'Route' doesn't exist". can any1 explains me what this error means?? and how can i remove this error?? I am sending my problems with attachment please have a look at this.. You have to do 4 steps in the order i say: 1) Read the answer you get from Merlin Moncure. 2) Read the error message you get on page 2 of your attachment. 3) If you don't see why the error is happening, go to step 1. 4) Next time don't send attachments in .docx or any other pay-per-view/pay-per-work format With best regards No Problem ;) Saqib Kazmi -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On 12/29/2011 09:19 AM, Merlin Moncure wrote: I'll pass, thanks for all your "help" guys. It's been a blast. I did not suggest that. I suggested they *might* be happening. In lieu of a reproducible test case (a couple of us took a stab at creating one ourselves and could not come up with your issue) or some other smoking gun it is something that has to ruled out. Statistically speaking, operator error is by far the most common cause of bug reports and as engineers we tend to rule out the most likely culprits first. It's nothing personal. By the way, I've been diagnosing and fixing other people's problems on this list for years and have a pretty good feel for what's a real problem or not. Your is one of those that can go either way and I was willing to take time out of my day, gratis, to help you fix it on your end and/or suggest a fix to the database itself. Since you are obviously unaware of the value of that help, not to mention Tom's incredibly precious time, it is your curse to have to reset your sequences for ever and ever. Happy Holidays. To add. It is the difference between working the solution and working the problem. The problem was you where seeing unexpected behavior. That is given. The solution at this point is a work in progress and without exploring all avenues will remain so. The bigger picture is that potentially this is something that could affect more than you and if that is the case, or not, it would nice to nip it in the bud sooner rather than later. merlin -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Thu, Dec 29, 2011 at 10:20 AM, Greg Donald wrote:
> On Wed, Dec 28, 2011 at 4:57 PM, Tom Lane wrote:
>>> < SELECT pg_catalog.setval('cp_state_id_seq', 52, true);
>>> > SELECT pg_catalog.setval('cp_state_id_seq', 1, false);
>>
>> These "grep" calls are showing just exactly not enough to prove
>> anything.
>
> Those grep calls prove my old backups with 8.4 pg_dump were good to go
> and now they are not with 9.1 pg_dump.
>
>> I remain unclear as to what state is actually in the
>> database, or what is being dumped,
>
> The whole thing is being dumped. One command /usr/bin/pg_dump cp,
> that's it, nothing special.
if you take a bzipped schema only dump (pg_dump -s), I'd be happy to
look it over and eliminate the 'operator error' class of issues that
Tom is thinking might be happening. private mail is ok.
merlin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On 12/29/2011 08:13 AM, Greg Donald wrote: On Wed, Dec 28, 2011 at 4:58 PM, Adrian Klaver wrote: What is the pg_dump command, with options, you are using? My backup shell script contains: /usr/bin/pg_dump cp | bzip2> $FILE One possible issue that I see is the lack of explicit options. Given that you say you have two Postgres clusters on the machine it is entirely possible that the above command is picking up ENVIRONMENT variables that are pointing to a database different from the one you think. Try the command with explicit options, i.e. -p some_port -d database_name, that you know point to the database you want. -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Wed, Dec 28, 2011 at 4:58 PM, Adrian Klaver wrote: > What is the pg_dump command, with options, you are using? My backup shell script contains: /usr/bin/pg_dump cp | bzip2 > $FILE -- Greg Donald -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Thu, Dec 29, 2011 at 10:53 AM, Greg Donald wrote: > On Thu, Dec 29, 2011 at 10:27 AM, Merlin Moncure wrote: >> if you take a bzipped schema only dump (pg_dump -s), I'd be happy to >> look it over and eliminate the 'operator error' class of issues that >> Tom is thinking might be happening. private mail is ok. > > Operator error? Wow.. so now I'm doing it wrong? > > I'll pass, thanks for all your "help" guys. It's been a blast. I did not suggest that. I suggested they *might* be happening. In lieu of a reproducible test case (a couple of us took a stab at creating one ourselves and could not come up with your issue) or some other smoking gun it is something that has to ruled out. Statistically speaking, operator error is by far the most common cause of bug reports and as engineers we tend to rule out the most likely culprits first. It's nothing personal. By the way, I've been diagnosing and fixing other people's problems on this list for years and have a pretty good feel for what's a real problem or not. Your is one of those that can go either way and I was willing to take time out of my day, gratis, to help you fix it on your end and/or suggest a fix to the database itself. Since you are obviously unaware of the value of that help, not to mention Tom's incredibly precious time, it is your curse to have to reset your sequences for ever and ever. Happy Holidays. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Postgresql Replication Comparison Required
I am doing POC on Posgtresql replication. I am using latest version of postgresql i.e. 9.1. There are multiple replication solutions avaliable in the market (PGCluster, Pgpool-II, Slony-I). Postgresql also provide in-built replication solutions (Streaming replication, Warm Standby and hot standby). I am confused which solution is best for the financial application for which I am doing POC. The application will write around 160 million records with row size of 2.5 KB in database. My questions is for following scenarios which replication solution will be suitable: If I would require replication for backup purpose only If I would require to scale the reads If I would require High Avaliability and Consistency Also It will be very helpful if you can share the perfomance or experience with postgresql replication solutions. Thanks
Re: [GENERAL] Unable to Increase the column which was part of Primary key
karthikeyan wrote:
> Hi,
>
> I am trying to increase size of the column which was/is part of the Primary.
>
> Exiting table
> CREATE TABLE test_dim_store
> (
> storek integer NOT NULL DEFAULT
> nextval('dim_store_storek_seq1'::regclass),
> retailerk character varying(10) NOT NULL,
> store_nbr character varying(5) NOT NULL,
> store_name character varying(25) NOT NULL,
> CONSTRAINT test_dim_store_pkey PRIMARY KEY (retailerk, store_nbr)
> )
> WITHOUT OIDS;
>
> I am trying to increase size of the column - store_nbr (which was part of
> the Primary) from Varchar(5) to varchar(10).
>
> I tried the following :
> 1) drop the Primary key - ALTER TABLE test_dim_store DROP CONSTRAINT
> test_dim_store_pkey ;
> 2) Increase the size of Column - store_nbr - ALTER TABLE test_dim_store
> ALTER COLUMN store_nbr TYPE varchar(10);
>
> Error message:
>
>
> ERROR: xdb-83016: cannot alter scatter column
> relation "test_dim_store" column "store_nbr"
>
> ** Error **
>
> ERROR: xdb-83016: cannot alter scatter column
> relation "test_dim_store" column "store_nbr"
> SQL state: 42809
works for me:
test=# create sequence dim_store_storek_seq1;
CREATE SEQUENCE
Time: 1,029 ms
test=*# CREATE TABLE test_dim_store
test-# (
test(# storek integer NOT NULL DEFAULT
test(# nextval('dim_store_storek_seq1'::regclass),
test(# retailerk character varying(10) NOT NULL,
test(# store_nbr character varying(5) NOT NULL,
test(# store_name character varying(25) NOT NULL,
test(# CONSTRAINT test_dim_store_pkey PRIMARY KEY (retailerk,
store_nbr)
test(# )
test-# WITHOUT OIDS;
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"test_dim_store_pkey" for table "test_dim_store"
CREATE TABLE
Time: 83,074 ms
test=*# alter table test_dim_store alter column store_nbr type
varchar(10);
ALTER TABLE
Time: 19,384 ms
I'm using 9.1.2.
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Thu, Dec 29, 2011 at 10:27 AM, Merlin Moncure wrote: > if you take a bzipped schema only dump (pg_dump -s), I'd be happy to > look it over and eliminate the 'operator error' class of issues that > Tom is thinking might be happening. private mail is ok. Operator error? Wow.. so now I'm doing it wrong? I'll pass, thanks for all your "help" guys. It's been a blast. -- Greg Donald -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Verifying a timestamp is null or in the past
Hello fellow postgres users,
in my game using PostgreSQL 8.4.9 players can
purchase a VIP ("very important person") status:
# \d pref_users;
Table "public.pref_users"
Column |Type | Modifiers
+-+---
id | character varying(32) | not null
vip| timestamp without time zone |
I.e. if vip has never been purchased it will be NULL.
An expired vip will be < CURRENT_TIMESTAMP.
I'm trying to create PL/pgSQL procedure allowing
players with enough vip status left
to give a week of it to other users, as a "gift":
create or replace function pref_move_week(_from varchar,
_to varchar) returns void as $BODY$
declare
has_vip boolean;
begin
select vip > current_timestamp + interval '1 week'
into has_vip from pref_users where id=_from;
if (not has_vip) then
return;
end if;
update pref_users set vip = current_timestamp - interval '1
week' where id=_from;
update pref_users set vip = current_timestamp + interval '1
week' where id=_to;
end;
$BODY$ language plpgsql;
This procedure compiles, but unfortunately
the IF-statement falls through for
_from players with vip=NULL
Does anybody please have an advice
what to change here and maybe the
has_vip variable isn't really needed either?
Thank you
Alex
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Refine Form of My querry
On 12/29/11 3:11 AM, saqi...@igis.nust.edu.pk wrote: Hi every1 how are u all??? Members i am new in postgres and want to work on pgrouting but i am facing some issue with it. Will u please help me??? I have loaded my line shapefile in pgadmin environment, which creates a table name 'Route', but when i made a query 'Create View' at it, it will show an error that "Relation 'Route' doesn't exist". can any1 explains me what this error means?? and how can i remove this error?? I'm guessing you need double quotes around your table name.. e.g. "Routes".. in your view definition as the table name may be case sensitive, in your case. -ds -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Wed, Dec 28, 2011 at 4:57 PM, Tom Lane wrote: > These "grep" calls are showing just exactly not enough to prove > anything. I remain unclear as to what state is actually in the > database, or what is being dumped, but I suspect at this point that you > may have multiple sequences of the same names in different schemas. I have one schema and one database on that one database server. And like I said, it worked fine until 9.1. If it was any of those reasons you suggest, would I not have experienced the same problem back in 8.4? I would think so. -- Greg Donald -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PostgreSQL 9.1 pg_dump setval() sets wrong value
On Wed, Dec 28, 2011 at 4:57 PM, Tom Lane wrote:
>> < SELECT pg_catalog.setval('cp_state_id_seq', 52, true);
>> > SELECT pg_catalog.setval('cp_state_id_seq', 1, false);
>
> These "grep" calls are showing just exactly not enough to prove
> anything.
Those grep calls prove my old backups with 8.4 pg_dump were good to go
and now they are not with 9.1 pg_dump.
> I remain unclear as to what state is actually in the
> database, or what is being dumped,
The whole thing is being dumped. One command /usr/bin/pg_dump cp,
that's it, nothing special.
--
Greg Donald
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Verifying a timestamp is null or in the past
Alexander Farber wrote:
> Hello fellow postgres users,
>
> in my game using PostgreSQL 8.4.9 players can
> purchase a VIP ("very important person") status:
>
> # \d pref_users;
> Table "public.pref_users"
>Column |Type | Modifiers
> +-+---
> id | character varying(32) | not null
> vip| timestamp without time zone |
>
> I.e. if vip has never been purchased it will be NULL.
>
> An expired vip will be < CURRENT_TIMESTAMP.
>
> I'm trying to create PL/pgSQL procedure allowing
> players with enough vip status left
> to give a week of it to other users, as a "gift":
>
> create or replace function pref_move_week(_from varchar,
> _to varchar) returns void as $BODY$
> declare
> has_vip boolean;
> begin
>
> select vip > current_timestamp + interval '1 week'
> into has_vip from pref_users where id=_from;
>
> if (not has_vip) then
> return;
> end if;
>
> update pref_users set vip = current_timestamp - interval '1
> week' where id=_from;
> update pref_users set vip = current_timestamp + interval '1
> week' where id=_to;
>
> end;
> $BODY$ language plpgsql;
>
> This procedure compiles, but unfortunately
> the IF-statement falls through for
> _from players with vip=NULL
>
> Does anybody please have an advice
> what to change here and maybe the
> has_vip variable isn't really needed either?
Try "if (not coalesce(has_vip, false)) then ..."
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql Replication Comparison Required
Hello, in general my advice would be to stick with native features, therefore use either Streaming Replication (or alternatively log shipping replication). You might need some tools to help you manage the cluster, clients routing and balancing but I suggest you look into this later. On Thu, 29 Dec 2011 16:55:00 +0530, saurabh gupta wrote: If I would require replication for backup purpose only For disaster recovery, you need physical base backups with continous archiving (http://www.postgresql.org/docs/9.1/interactive/continuous-archiving.html) If I would require to scale the reads You need Hot Standby here (and you might need to route read only applications to one of the slaves somehow - but you can worry about this later). If I would require High Avaliability and Consistency Streaming replication. With 9.1 you also have Synchronous Streaming Replication which means you have zero data loss of committed transactions within your PostgreSQL cluster. Another useful tool you might want to look into is repmgr (www.repmgr.org). Also It will be very helpful if you can share the perfomance or experience with postgresql replication solutions. I wish I could help you more here, but most of our professional work is performed under strict NDAs. An interesting and useful documentation section is this also: http://www.postgresql.org/docs/9.1/interactive/high-availability.html I hope this helps. Cheers, Gabriele -- Gabriele Bartolini - 2ndQuadrant Italia PostgreSQL Training, Services and Support gabriele.bartol...@2ndquadrant.it - www.2ndQuadrant.it -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Verifying a timestamp is null or in the past
Thank you Andreas - now that one case works ok,
On Thu, Dec 29, 2011 at 7:44 PM, Andreas Kretschmer
wrote:
> Try "if (not coalesce(has_vip, false)) then ..."
but the other case not:
# create or replace function pref_move_week(_from varchar,
_to varchar) returns void as $BODY$
declare
has_vip boolean;
begin
select vip > current_timestamp + interval '1 week'
into has_vip from pref_users where id=_from;
if (not coalesce(has_vip, false)) then
return;
end if;
update pref_users set vip = current_timestamp -
interval '1 week' where id=_from;
update pref_users set vip = current_timestamp +
interval '1 week' where id=_to;
end;
$BODY$ language plpgsql;
# select id,vip from pref_users where id in ('DE16290', 'DE1');
id|vip
-+
DE1 | 2012-01-05 17:43:11.589922
DE16290 |
(2 rows)
(I.e. player DE1 has vip until May and should
be able to give a week of VIP to DE16290, but):
# select pref_move_week('DE1', 'DE16290');
pref_move_week
(1 row)
# select id,vip from pref_users where id in ('DE16290', 'DE1');
id|vip
-+
DE1 | 2012-01-05 17:43:11.589922
DE16290 |
(2 rows)
(For some reason nothing has changed?)
Regards
Alex
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Verifying a timestamp is null or in the past
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Alexander Farber
Sent: Thursday, December 29, 2011 3:01 PM
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Verifying a timestamp is null or in the past
Thank you Andreas - now that one case works ok,
On Thu, Dec 29, 2011 at 7:44 PM, Andreas Kretschmer
wrote:
> Try "if (not coalesce(has_vip, false)) then ..."
but the other case not:
# create or replace function pref_move_week(_from varchar,
_to varchar) returns void as $BODY$
declare
has_vip boolean;
begin
select vip > current_timestamp + interval '1 week'
into has_vip from pref_users where id=_from;
if (not coalesce(has_vip, false)) then
return;
end if;
update pref_users set vip = current_timestamp - interval '1
week' where id=_from;
update pref_users set vip = current_timestamp + interval '1
week' where id=_to;
end;
$BODY$ language plpgsql;
# select id,vip from pref_users where id in ('DE16290', 'DE1');
id|vip
-+
DE1 | 2012-01-05 17:43:11.589922
DE16290 |
(2 rows)
(I.e. player DE1 has vip until May and should be able to give a week of VIP
to DE16290, but):
# select pref_move_week('DE1', 'DE16290'); pref_move_week
(1 row)
# select id,vip from pref_users where id in ('DE16290', 'DE1');
id|vip
-+
DE1 | 2012-01-05 17:43:11.589922
DE16290 |
(2 rows)
(For some reason nothing has changed?)
Regards
Alex
--
Alexander,
The following update confuses me:
update pref_users set vip = current_timestamp - interval '1
week' where id=_from;
You end up setting "vip" to a date one week in the past ALWAYS; regardless
of whether subtracting a week from "VIP" would result in a time still in the
future.
I am thinking maybe you are not providing the correct update code? If the
code goes something like:
Update pref_users SET vip = vip + '1 week'::interval WHERE id = _to;
You are going to still have issues since adding anything to "NULL" results
in NULL. You probably want something like:
Update pref_users SET vip = COALESCE(vip, current_timestamp) + '1
week'::interval WHERE id = _to;
Adding a Raise Notice within the pl/pgsql block (just before the return
within the IF) would help you determine whether the "UPDATE" statements are
being reached (but have no effect) or whether the procedure is ending early.
Also, are you positive that the construct "... + '1 week'::interval", when
using the current_timestamp and VIP timestamp of '2010-01-05 17:43 ...',
indeed evaluates to "TRUE"?
David J.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL]
Might be discussed but not clear for the below query. In async. streaming replication do I need to run VACUUM & ANALYZE on both master & slave as to it is bit to bit replication. Bec, while querying on master getting below result, but slave's system table is not updated. select last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables where relname like 'test'; last_vacuum| last_autovacuum | last_analyze | last_autoanalyze --+-+--+-- 2011-12-30 11:14:02.802973+05:30 | | 2011-12-30 11:14:20.943012+05:30 | Slave: select last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables where relname like 'test'; last_vacuum | last_autovacuum | last_analyze | last_autoanalyze -+-+--+-- | | |
[GENERAL] streaming replication vacuum
Might be discussed but not clear for the below query. In async. streaming replication do I need to run VACUUM & ANALYZE on both master & slave. Bec, while querying on master getting below result, but slave's system table is not updated. select last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables where relname like 'test'; last_vacuum| last_autovacuum | last_analyze | last_autoanalyze --+-+--+-- 2011-12-30 11:14:02.802973+05:30 | | 2011-12-30 11:14:20.943012+05:30 | Slave: select last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables where relname like 'test'; last_vacuum | last_autovacuum | last_analyze | last_autoanalyze -+-+--+-- | | |
