When reviewing the vacuum logs, I notice that on any given day
autovacuum only seems to touch four of the tables in one of our
schemas (not counting toast tables). However, if I look at the
pgstatspack output for the same day, I see that there are plenty of
other tables receiving a high number of i
On Wed, Jul 29, 2009 at 11:29 AM, Tom Lane wrote:
> Ain't transactional DDL wonderful?
Yes. :-)
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Robert Haas writes:
> Hmm, good point. It seems like it would be useful to force the
> planner into use the other plan and get EXPLAIN ANALYZE output for
> that for comparison purposes, but off the top of my head I don't know
> how to do that.
The standard way is
begin;
drop ind
On Wed, Jul 29, 2009 at 10:22 AM, Tom Lane wrote:
> Robert Haas writes:
>> If love is an uncommon word, there's no help for queries of this type
>> being slow unless the GIN index can return the results in order. But
>> if love is a common word, then it would be faster to do an index scan
>> by t
If love is an uncommon word, there's no help for queries of this type
being slow unless the GIN index can return the results in order. But
if love is a common word, then it would be faster to do an index scan
by timestamp on the baserel and then treat comment_tsv @@
plainto_tsquery('love') as a
Robert Haas writes:
> If love is an uncommon word, there's no help for queries of this type
> being slow unless the GIN index can return the results in order. But
> if love is a common word, then it would be faster to do an index scan
> by timestamp on the baserel and then treat comment_tsv @@
>
On Mon, Jul 20, 2009 at 8:12 AM, Oleg Bartunov wrote:
>> Here's a couple of queries:
>>
>> archive=> explain analyze select * from a where comment_tsv @@
>> plainto_tsquery('love') order by timestamp desc limit 24 offset 0;
>>
>> QUERY PLAN
>> --
>> Limit (cost=453248.73..453248.79 rows=2
On Tue, Jul 28, 2009 at 7:21 PM, Greg Smith wrote:
> On Tue, 28 Jul 2009, Scott Marlowe wrote:
>
>> Just FYI, I ran the same basic test but with -c 10 since -c shouldn't
>> really be greater than -s
>
> That's only true if you're running the TPC-B-like or other write tests,
> where access to the sm
On Tue, 28 Jul 2009, Dave Youatt wrote:
Unlikely. Different threads on the same CPU core share their resources, so they
don't
need an explicit communication channel at all (I'm simplifying massively here).
A real
interconnect is only needed between CPUs and between different cores on a CPU,
an
On Tue, 28 Jul 2009, Scott Carey wrote:
On 7/28/09 1:28 PM, "Greg Smith" wrote:
On Tue, 28 Jul 2009, Matthew Wakeling wrote:
Unlikely. Different threads on the same CPU core share their resources, so
they don't need an explicit communication channel at all (I'm simplifying
massively here). A
Kevin Grittner wrote:
Thomas Zaksek wrote:
Is this query plan near to optimal or are their any serious flaws?
I didn't see any problem with the query, but with the information
provided, we can't really tell if you need to reconfigure something,
or maybe add an index.
The plan gen
11 matches
Mail list logo
