On Sun, Feb 28, 2010 at 8:09 PM, Plugge, Joe R. wrote:
> I have a very busy system that takes about 9 million inserts per day and each
> record gets updated at least once after the insert (all for the one same
> table), there are other tables that get hit but not as severely. As
> suspected I
I have a very busy system that takes about 9 million inserts per day and each
record gets updated at least once after the insert (all for the one same
table), there are other tables that get hit but not as severely. As suspected
I am having a problem with table bloat. Any advice on how to be m
Josh Berkus wrote:
Xufei,
List changed to psql-performance, which is where this discussion belongs.
I am testing the index used by full text search recently.
I have install 8.3.9 and 8.4.2 separately.
In 8.3.9, the query plan is like:
postgres=# explain SELECT s.name as source , t.name as
On 2/28/10 1:51 PM, Kenneth Marshall wrote:
> On Sun, Feb 28, 2010 at 12:29:14PM -0800, Josh Berkus wrote:
>>> However the same query against the base table when specifying the check
>>> constraint key in the where clause produces sequential scans:
>> Does the "master" table have the same indexes
Xufei,
List changed to psql-performance, which is where this discussion belongs.
> I am testing the index used by full text search recently.
>
> I have install 8.3.9 and 8.4.2 separately.
>
> In 8.3.9, the query plan is like:
>
> postgres=# explain SELECT s.name as source , t.name as target F
On Sun, Feb 28, 2010 at 12:29:14PM -0800, Josh Berkus wrote:
>
> > However the same query against the base table when specifying the check
> > constraint key in the where clause produces sequential scans:
>
> Does the "master" table have the same indexes as the slave partitions?
>
> --Josh Berk
> However the same query against the base table when specifying the check
> constraint key in the where clause produces sequential scans:
Does the "master" table have the same indexes as the slave partitions?
--Josh Berkus
--
Sent via pgsql-performance mailing list (pgsql-performance@postgres
All,
I'm seeing in a production database two problems with query rowcount
estimation:
(1) Estimates for the number of rows in an outer join do not take into
account any constraint exclusion (CE) in operation.
(2) Row estimates do not take into account if the unique indexes on the
child partition
Chris writes:
> @Tom Lane:
> As I mentioned above I am not doing everything in a single
> transaction. However I do want to try your suggestion regarding
> getting a "memory context map". But I'm afraid I don't know how to do
> what you are describing. How can I set the ulimit of postmaster?
Depe
