According to the manual (9.1), pg_stat_get_last_vacuum_time() returns
timestamptz | Time of the last non-FULL vacuum initiated by the
| user on this table
Why are full vacuums excluded from this statistic? It looks like there's
no way to get the date of the last manual vacuum,
On 2013-03-26 19:28, Kevin Grittner wrote:
>> Why are full vacuums excluded from this statistic? It looks like there's
>> no way to get the date of the last manual vacuum, if only full vacuums
>> are performed.
>
> Because FULL is a bit of a misnomer -- there are important things a
> non-FULL vacu
On 2013-03-28 13:11, Martín Marqués wrote:
> 2013/3/27 CR Lender :
>> In this case I was only trying to make sense of an existing database
>> (8.3). The statistics in pg_stats were way off for some tables, so I
>> wanted to see if (auto)vacuum and (auto)a
On 2013-03-28 20:44, Kevin Grittner wrote:
> CR Lender wrote:
>
>> The database is running on PostgreSQL 8.3.6.
>
>> I've read the manual more carefully now, and I can't see any mention of
>> what VACUUM does that VACUUM FULL does not. The point about extre
On 2013-03-31 18:31, CR Lender wrote:
> On 2013-03-28 20:44, Kevin Grittner wrote:
>> CR Lender wrote:
>>> I've read the manual more carefully now, and I can't see any mention of
>>> what VACUUM does that VACUUM FULL does not. The point about extreme
>&
On 2013-04-09 00:09, Kevin Grittner wrote:
> I'm not sure that what we're doing now is correct, but updating
> things as if a normal vacuum had been done would *not* be the thing
> to do. For starters, VACUUM FULL blows away the free space map and
> visibility map for a table. Among other things,
I have two tables with countries and persons living in those countries:
create table countries (
codechar(2) not null primary key,
eu boolean not null
);
insert into countries values
('AR', false),
('BE', true),
('CH', f
On 2013-04-26 12:17, D'Arcy J.M. Cain wrote:
> On Fri, 26 Apr 2013 11:01:28 +0200
> CR Lender wrote:
>> create table countries (
>> codechar(2) not null primary key,
>
> Isn't this redundant? Primary keys are always NOT NULL.
Yes, I fo
Sorry for the late reply, I had to give this some time to digest.
I'm still trying to wrap my head around the concept that triggers don't
"belong" to a table...
On 2013-04-26 17:15, Richard Huxton wrote:
> On 26/04/13 10:01, CR Lender wrote:
> I think this is more a pro
On 2013-05-14 19:32, Paul Jungwirth wrote:
> The UTF-8 encoding for a pound sign is 0xc2a3, not just 0xa3. You
> might want to make sure your PHP file is correct.
Just for the record, the Unicode code point for the pound symbol (£) is
actually 0x00A3. 0xC2A3 is the Hangul syllable Syuh (슣).
- crl
On 2013-05-15 00:31, Chris Angelico wrote:
> Which, in UTF-8, is represented by the byte sequence C2 A3. (The
> latter would be represented as EC 8A A3.)
Right, my bad.
I read Unicode instead of UTF-8.
- crl
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On 2013-09-19 02:01, Juan Daniel Santana Rodes wrote:
> I am programming a procedure in plpgsql language and it must return a
> boolean response. The procedure must return TRUE if the query is
> semantically correct and if not correct, return FALSE. This must be
> done without running the query.
Y
12 matches
Mail list logo
