On Wed, Jul 2, 2014 at 7:50 AM, Rich Shepard
wrote:
> On Wed, 2 Jul 2014, David G Johnston wrote:
>
> or if you want to do it as part of creating a new user:
>>
>> CREATE ROLE new_management_user
>> [other stuff here]
>> IN ROLE management;
>>
>> http://www.postgresql.org/docs/9.2/interactive/sq
While I agree that an equality operator doesn't really make sense for json
operationally, there are certain maintenance reasons why it may come in
handy. Removing duplicate records comes to mind.
Other than adding basic stats to necessary columns, I would say that the
equality operator is really o
elapsed 0.01 sec.
INFO: vacuuming "pg_toast.pg_toast_51822"
INFO: index "pg_toast_51822_index" now contains 0 row versions in 1 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
table should be. I'm not sure how you would factor the
toast table into that estimate.
-G
On Tue, Oct 29, 2013 at 2:05 PM, Tom Lane wrote:
> Gregory Haase writes:
> > I've isolated the problem to the json field not showing up in pg_stats,
> > which affects the calcul
erce writes:
> > On 10/29/2013 12:41 PM, Gregory Haase wrote:
> >> db_name=# VACUUM FULL VERBOSE table_schema.table_name;
> >> INFO: vacuuming "table_schema.table_name"
> >> INFO: "table_name": found 2 removable, 29663 nonremovable row
> &g
ng to throw out any notion of updates or
deletes as cause for bloat on this particular table.
-G
On Tue, Oct 29, 2013 at 12:53 PM, Gregory Haase wrote:
> So, between yesterday and today we actually failed over to our hot-standby
> instance and the issue hasn't changed. I don't
So, between yesterday and today we actually failed over to our hot-standby
instance and the issue hasn't changed. I don't think you can have a pending
transaction across streaming replication.
On Tue, Oct 29, 2013 at 12:49 PM, John R Pierce wrote:
> On 10/29/2013 12:41 PM, Gregor
l.org/wiki/Show_database_bloat seems to
correlate with the wasted bytes reported by nagios though.
Greg Haase
On Tue, Oct 29, 2013 at 7:06 AM, Merlin Moncure wrote:
> On Tue, Oct 29, 2013 at 5:38 AM, Chris Travers
> wrote:
> >
> >
> >
> > On Mon, Oct 28, 2013 at 4:
I have a table that is triggering my nagios database bloat alert regularly.
Usually, I have to give it the vacuum full more than once to get it under
the threshold. Today I tried repeatedly and cannot get the alert to resolve.
I had a discussion with one of the primary developers about how the tab
Before going through something like delayed replication, you really want to
consider using zfs or lvm and taking regular snapshots on your hot or warm
standby. In the event of the accidental table drop, you can just roll back
to the snapshot prior and then do PITR from there.
Greg Haase
On Fri,
I'm curious what the following would show:
time echo '\\timing select 1 from dual' | $PG_ROOT/bin/psql test >>
out.txt
Greg Haase
On Sep 24, 2013 4:01 PM, "Daniel Tahara" wrote:
>
> On Tue, Sep 24, 2013 at 6:37 PM, Daniel Tahara wrote:
>
>> time echo '\\timing select msg from test' |
I would look towards how PostGis handles the Tiger census data for
guidance. It's a similar, massive data set.
Greg Haase
On Sep 20, 2013 9:47 AM, "Jeff Janes" wrote:
> On Thu, Sep 19, 2013 at 12:02 AM, Dave Potts wrote:
>
>> Hi List
>>
>> I am looking for some general advice about the best was
most elegant, but I'd rather have a failed
pg_stop_backup command than a pg_start_backup command that is left open
indefinitely.
Greg Haase
On Tue, Sep 17, 2013 at 12:33 PM, Vick Khera wrote:
>
> On Wed, Sep 11, 2013 at 8:00 PM, Gregory Haase wrote:
>
>> Typically how fast is a
al minutes, several hours?
Thanks,
-G
On Wed, Sep 11, 2013 at 4:46 PM, Steven Schlansker wrote:
>
> On Sep 11, 2013, at 4:29 PM, Gregory Haase
> wrote:
>
> > I was trying to figure out how to get the following syntax to work:
> >
> > echo "select pg_start_bac
I was trying to figure out how to get the following syntax to work:
echo "select pg_start_backup('zfs_snapshot'); \\! zfs snapshot
zroot/zpgsql@test; \\ select pg_stop_backup();" | psql postgres
The above command successfully starts the backup and creates the snapshot
but then fails to stop the b
I am working on a date-based partitioning framework and I would really like
to have a single function that could be used as trigger for any table that
needs to be partitioned by day. I am working in a rails environment, so
every table has a created_at datetime field.
I created my generic function:
16 matches
Mail list logo
