On Mon, Nov 11, 2013 at 1:57 PM, Jim Nasby wrote:
> We do run a regular process to remove older rows... I thought we were
> vacuuming after that process but maybe not.
Could be a long query, idle-in-transaction, prepared transaction, or
hot standby feedback gone bad, too.
--
Sent via pgsql-per
On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby wrote:
> Postgres 9.1.9.
>
> explain analyze select min(insert_time) from cnu_stats.page_hits_raw ;
>
> QUERY PLAN
> --
On Wed, Dec 5, 2012 at 10:28 AM, Shaun Thomas wrote:
> Hey guys,
>
> This isn't a question, but a kind of summary over a ton of investigation
> I've been doing since a recent "upgrade". Anyone else out there with
> "big iron" might want to confirm this, but it seems pretty reproducible.
> This see
On Fri, Nov 30, 2012 at 12:38 PM, Bruce Momjian wrote:
> Or Debian. Not sure what would justify use of Ubuntu as a server,
> except wanting to have the exact same OS as their personal computers.
We have switched from Debian to Ubuntu: there is definitely non-zero
value in the PPA hosting (althou
On Mon, Oct 8, 2012 at 1:25 PM, Navaneethan R wrote:
> On Tuesday, October 9, 2012 1:40:08 AM UTC+5:30, Steve Crawford wrote:
>> On 10/08/2012 08:26 AM, Navaneethan R wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >I have 10 million records in my postgres table.I am running the
>> > database in ama
On Wed, Sep 19, 2012 at 5:34 AM, mal.oracledba wrote:
> Running hammer ora TPC-C type load. Under 20 user load (no key and think)
> getting approx 180,000 TPM - which is about half of what I get with another
> database vendor.
>
> tracing the process (strace -r) I get outtput like that below - a l
On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky wrote:
> Hi
> I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got
> the 15-20% performance drop of PostgreSQL 9.2 on AMD chipsets (880G,
> 990X).
>
> CentOS 6.3 x86_64
> PostgreSQL 9.2
> cpufreq scaling_governor - performance
>
On Thu, Sep 6, 2012 at 6:50 PM, charles_xie wrote:
> Hi，
>Thanks for your advice.i know the basic monitoring skill,because the
> postgresql database is used for the factory production , so I hope they can
> run normal and exert more perfect performance. so i need to be considered
> from the p
On Tue, Sep 4, 2012 at 12:12 AM, charles_xie wrote:
> Hi all,
> i have 5 servers that have been installing postgresql .In order to
> know the postgresql working status and monitor them ,moreover i don't want
> to use the monitor tools .I want to use the SQL commands to monitoring
> pos
On Thu, Aug 30, 2012 at 1:34 AM, Liron Shiri wrote:
> We do not use in-database operators to modify the toasted data.
> The update operations we perform on the problematic table are in the form of
>
> UPDATE foo SET field='value' WHERE nid = to_uid(#objId#)
Ah, well, there goes that idea, althoug
On Mon, Aug 27, 2012 at 11:24 PM, Liron Shiri wrote:
> There were no "hot standby" configuration, but the DB has start grow fast
> after restoring from a base backup as described in
> http://www.postgresql.org/docs/8.3/static/continuous-archiving.html#BACKUP-BASE-BACKUP
I'm trying to confirm a
On Tue, Aug 28, 2012 at 1:57 AM, Daniel Farina wrote:
> My database has taken many days (over a week) to stabilize. I was
> about to write that it never stops growing (we'd eventually have to
> VACUUM FULL or do a column rotation), but that is not true. This
> graph is
On Mon, Aug 27, 2012 at 11:24 PM, Liron Shiri wrote:
> There were no "hot standby" configuration, but the DB has start grow fast
> after restoring from a base backup as described in
> http://www.postgresql.org/docs/8.3/static/continuous-archiving.html#BACKUP-BASE-BACKUP
Very interesting. That
On Sun, Aug 26, 2012 at 5:46 AM, Liron Shiri wrote:
> Hi,
>
>
>
> We have a table which its TOAST table size is 66 GB, and we believe should
> be smaller.
>
> The table size is 472 kb. And the table has 4 columns that only one of them
> should be toasted.
>
>
>
> The table has only 8 dead tuples,
On Wed, Jul 11, 2012 at 6:41 PM, Craig Ringer wrote:
> On 07/12/2012 06:51 AM, Daniel Farina wrote:
>>
>> 15x slower. This is a Macbook Air with full disk encryption and SSD
>> disk with fsync off, e.g. a very typical developer configuration.
>
> Don't use full di
On Wed, Jul 11, 2012 at 7:05 AM, Tom Lane wrote:
> Daniel Farina writes:
>> TRUNCATE should simply be very nearly the fastest way to remove data
>> from a table while retaining its type information, and if that means
>> doing DELETE without triggers when the table is
On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer wrote:
> Hi
>
> After seeing a few discussions here and on Stack Overflow I've put together
> a quick explanation of why "DELETE FROM table;" may be faster than "TRUNCATE
> table" for people doing unit testing on lots of tiny tables, people who're
> do
On Fri, Jul 6, 2012 at 4:29 AM, Craig Ringer wrote:
> 1) Truncate each table. It is too slow, I think, especially for empty
> tables.
>
> Really?!? TRUNCATE should be extremely fast, especially on empty tables.
>
> You're aware that you can TRUNCATE many tables in one run, right?
>
> TRUNCATE TABL
On Thu, Jul 5, 2012 at 11:17 PM, Yan Chunlu wrote:
> I have grabbed one day slow query log and analyzed it by pgfouine, to my
> surprise, the slowest query is just a simple select statement:
>
> select diggcontent_data_message.thing_id, diggcontent_data_message.KEY,
> diggcontent_data_message.valu
On Tue, Jul 3, 2012 at 10:43 PM, Craig Ringer wrote:
> On 07/04/2012 07:13 AM, Reza Taheri wrote:
>
> Following the earlier email introducing the TPC-V benchmark, and that we are
> developing an industry standard benchmarking kit for TPC-V using PostgreSQL,
> here is a specific performance issue w
20 matches
Mail list logo
