On Thu, 2013-10-03 at 11:53 -0700, bricklen wrote:
>
> On Thu, Oct 3, 2013 at 11:48 AM, Michael Graham
> wrote:
> Hi all,
>
> We partition the data in postgres in a per-month basis and run
> a script
> to delete old partition
p the autovacuumer temporarily (and cancel any on
going autovacuum) so that my script can remove the table that the
autovacuumer wants to vacuum?
I'm on 9.1.4 if it matter.
Cheers,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chang
p this from
happening? I'm not really in the position to have different users for
the modification of the table_list and the drops so I don't think I can
use different roles.
I'm pretty sure I can't do what I need as postgres doesn't support
triggers on DDL but may
) AS bb
ON aa.row_number=bb.row_number AND aa.id=bb.id;
So I was wondering if anyone had any better solutions.
Thanks,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
uot;traffic.public.logdata5queue"
Under those circumstances?
Cheers,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, 2011-08-03 at 10:17 -0400, Tom Lane wrote:
> Michael Graham writes:
> > Would my applications
> > constant polling of the queue mean that the lock could not be easily
> > obtained?
>
> Very possible, depending on what duty cycle is involved there.
Hm
der what circumstances it will be able
to return unused space to the OS in when it can't.
Cheers,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s at the
end of a table become entirely free and an exclusive table lock can be
easily obtained".
What does "easily obtained" mean in this context? Would my applications
constant polling of the queue mean that the lock could not be easily
obtained?
Cheers,
--
Michael Graham
--
e side of a WHERE-condition operator exactly matches an index, so
> you'd need to be looking for places where rearrangement could make
> that happen.
The reason I never showed you any was because I don't have any I was
just curious. But yeah making one side match an index exactly is
pr
s the
benefit. But in terms of driving the planner don't we always want to be
looking to move all the constants to one side of the expression since
the planner seems to like those?
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
nd to doing it or is there some
deeper reasons? It's not really important I'm just curious.
Cheers,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
random value to the freeze_max_age for all the old tables
when I start a new month? Or do the same with the freeze_min_age?
Perhaps I should just force a vacuum on some of the tables the break it?
Cheers,
--
Michael Graham
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
12 matches
Mail list logo
