On 03/11/2015 08:52 AM, pinker wrote:
Adrian Klaver-4 wrote
Also per Kevin Grittner and Tom Lane there
is a Nabble issue at work where the list here is not seeing all the
information. Example:
It's because I edited some post. Then is visible only on nabble because
edited version isn't sent bac
Adrian Klaver-4 wrote
> Also per Kevin Grittner and Tom Lane there
> is a Nabble issue at work where the list here is not seeing all the
> information. Example:
It's because I edited some post. Then is visible only on nabble because
edited version isn't sent back to the mailing list.
Adrian Kl
On 03/09/2015 09:19 AM, Joshua D. Drake wrote:
On 03/09/2015 08:57 AM, Adrian Klaver wrote:
On 03/09/2015 08:49 AM, Kevin Grittner wrote:
pinker wrote:
INFO: vacuuming "my_table"
INFO: "my_table": found 0 removable, 3043947 nonremovable row
versions in 37580 pages
DETAIL: 0 dead row ver
Joshua D. Drake wrote:
> On 03/09/2015 08:57 AM, Adrian Klaver wrote:
>> On 03/09/2015 08:49 AM, Kevin Grittner wrote:
>>> pinker wrote:
DETAIL: 0 dead row versions cannot be removed yet.
>>>
>>> So there are no longer any dead rows being left behind, right?
>>>
>>> Why are we still discuss
On 03/09/2015 08:57 AM, Adrian Klaver wrote:
On 03/09/2015 08:49 AM, Kevin Grittner wrote:
pinker wrote:
INFO: vacuuming "my_table"
INFO: "my_table": found 0 removable, 3043947 nonremovable row
versions in 37580 pages
DETAIL: 0 dead row versions cannot be removed yet.
So there are no l
On Mon, 9 Mar 2015 09:05:07 -0700 (MST)
pinker wrote:
>
> > So there are no longer any dead rows being left behind, right?
> >
> > Why are we still discussing this? Do you have some other question?
>
> There are no dead rows, but postgres still cannot reuse the space because of
> 3043947 nonr
> So there are no longer any dead rows being left behind, right?
>
> Why are we still discussing this? Do you have some other question?
There are no dead rows, but postgres still cannot reuse the space because of
3043947 nonremovable row versions ..
INFO: vacuuming "my_table"
INFO: "my_table
On 03/09/2015 08:49 AM, Kevin Grittner wrote:
pinker wrote:
INFO: vacuuming "my_table"
INFO: "my_table": found 0 removable, 3043947 nonremovable row versions in
37580 pages
DETAIL: 0 dead row versions cannot be removed yet.
So there are no longer any dead rows being left behind, right?
On 03/09/2015 08:05 AM, pinker wrote:
select * from pg_stat_activity where state ilike 'idle in transaction%' it's
empty.
And there is no relation between this table and the tables or functions
being queried?
no...
If snapshot is what I think it means, you might want to point them at:
h
pinker wrote:
> INFO: vacuuming "my_table"
> INFO: "my_table": found 0 removable, 3043947 nonremovable row versions in
> 37580 pages
> DETAIL: 0 dead row versions cannot be removed yet.
So there are no longer any dead rows being left behind, right?
Why are we still discussing this? Do you
and select txid_current_snapshot() - 1694632069:1694632069:
select distinct xmin::text::bigint from sms_actual_mapper order by 1 desc
1694595273
--
View this message in context:
http://postgresql.nabble.com/VACUUM-FULL-doesn-t-reduce-table-size-tp5840782p5841128.html
Sent from the PostgreSQL
select * from pg_stat_activity where state ilike 'idle in transaction%' it's
empty.
>And there is no relation between this table and the tables or functions
being queried?
no...
>If snapshot is what I think it means, you might want to point them at:
>http://www.postgresql.org/docs/9.3/intera
On 03/09/2015 07:37 AM, pinker wrote:
Adrian Klaver-4 wrote
On 03/09/2015 07:08 AM, pinker wrote:
I did: select pg_cancel_backend(pid) from pg_stat_activity where usename
<>
'mine';
What makes you think that queries from usename = 'mine' are not important?
Because on production I don't have
Adrian Klaver-4 wrote
> On 03/09/2015 07:08 AM, pinker wrote:
>> I did: select pg_cancel_backend(pid) from pg_stat_activity where usename
>> <>
>> 'mine';
>
> What makes you think that queries from usename = 'mine' are not important?
>
> Because on production I don't have access to this table.
>
On 03/09/2015 07:08 AM, pinker wrote:
I did: select pg_cancel_backend(pid) from pg_stat_activity where usename <>
'mine';
What makes you think that queries from usename = 'mine' are not important?
Or to get back to the original request:
What does select * from pg_stat_activity show?
Also did
I did: select pg_cancel_backend(pid) from pg_stat_activity where usename <>
'mine';
and then tried again vacuum full:
INFO: vacuuming "my_table"
INFO: "my_table": found 0 removable, 3043947 nonremovable row versions in
37580 pages
DETAIL: 0 dead row versions cannot be removed yet.
CPU 1.07s/1.
On 03/09/2015 04:22 AM, pinker wrote:
Yes I have. Environment I'm working on is production snapshot, so there is no
active transactions that could block those blocks from being removed...
Well the below from your original post would say different:
VACUUM FULL VERBOSE output:
INFO: vacuuming
Vick Khera wrote
> On Fri, Mar 6, 2015 at 5:59 AM, pinker <
> pinker@
> > wrote:
>
>> I have deleted a large number of records from my_table, which originally
>> had
>> 288 MB. Then I ran vacuum full to make the table size smaller. After this
>> operation size of the table remains the same, desp
Yes I have. Environment I'm working on is production snapshot, so there is no
active transactions that could block those blocks from being removed...
--
View this message in context:
http://postgresql.nabble.com/VACUUM-FULL-doesn-t-reduce-table-size-tp5840782p5841085.html
Sent from the Postgr
David G Johnston writes:
> I have no experience here but given recent versions rewrite the table the
> vacuum verbose output shown seems unusual.
"vacuum verbose output shown?" There wasn't any.
[ digs about ... ]
Oh. The version of the message that nabble sent to the postgresql lists
was mis
Vick Khera wrote
> On Fri, Mar 6, 2015 at 5:59 AM, pinker <
> pinker@
> > wrote:
>
>> I have deleted a large number of records from my_table, which originally
>> had
>> 288 MB. Then I ran vacuum full to make the table size smaller. After this
>> operation size of the table remains the same, desp
On Fri, Mar 6, 2015 at 5:59 AM, pinker wrote:
> I have deleted a large number of records from my_table, which originally
> had
> 288 MB. Then I ran vacuum full to make the table size smaller. After this
> operation size of the table remains the same, despite of the fact that
> table
>
If your re
pinker wrote:
> Query output is empty...
I hope you read the whole paragraph, not just the last phrase.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@post
Query output is empty...
--
View this message in context:
http://postgresql.nabble.com/VACUUM-FULL-doesn-t-reduce-table-size-tp5840782p5840797.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
pinker wrote:
> I have deleted a large number of records from my_table, which originally had
> 288 MB. Then I ran vacuum full to make the table size smaller. After this
> operation size of the table remains the same, despite of the fact that table
> contains now only 241 rows and after rewriting it
I have deleted a large number of records from my_table, which originally had
288 MB. Then I ran vacuum full to make the table size smaller. After this
operation size of the table remains the same, despite of the fact that table
contains now only 241 rows and after rewriting it in classic way: CREAT
26 matches
Mail list logo
