On Thu, 12 Aug 2010, Brad Nicholson wrote:
On 10-08-12 03:22 AM, Arjen van der Meijden wrote:
On 12-8-2010 2:53 gnuo...@rcn.com wrote:
- The value of SSD in the database world is not as A Faster HDD(tm).
Never was, despite the naive' who assert otherwise. The value of SSD
is to enable BCNF da
On Thu, Aug 5, 2010 at 2:34 PM, Craig James wrote:
> => explain analyze select p.price, p.amount, p.units, s.catalogue_id,
> vn.version_id
> -> from plus p join sample s
> -> on (p.compound_id = s.compound_id and p.supplier_id = s.supplier_id)
> -> join version vn on (s.version_id = vn.version_id
Mark Kirkwood wrote:
> I'm guessing you meant to suggest setting effective_cache_size
> to 15GB (not 15MB)
Yes. Sorry about that.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On 18/08/10 06:19, Kevin Grittner wrote:
Since you haven't set effective_cache_size, you're discouraging some
types of plans which might be worth considering. This should
normally be set to the sum of your shared_buffers setting and
whatever is cached by the OS; try setting effective_cache_siz
On Tue, Aug 17, 2010 at 1:19 PM, Alexandre de Arruda Paes
wrote:
> Hi,
>
> PG 8.4.4
> I did't see any transactions locking this table and I think that CLUSTER
> will recreate the table.
Prepared transactions?
> This is a temporary table, with one DELETE, Some INSERTs and a lot of
> UPDATES. And
Hi,
PG 8.4.4
I have an strange problem:
carmen=# VACUUM FULL verbose tp93t;
INFO: vacuuming "public.tp93t"
INFO: "tp93t": found 0 removable, 71984 nonremovable row versions in 17996
pages
DETAIL: 70632 dead row versions cannot be removed yet.
Nonremovable row versions range from 1848 to 2032
Aaron Burnett wrote:
>>> 16 Gig RAM
>>> 192MB work_mem (increasing to 400MB didn't change the outcome)
>>
>> What other non-default settings do you have?
>
> maintenance_work_mem = 1024MB
> max_stack_depth = 8MB
> max_fsm_pages = 800
> max_fsm_relations = 2000
Since you haven't set e
Thanks for the response kevin. Answers interspersed below.
On 8/17/10 10:18 AM, "Kevin Grittner" wrote:
> "Aaron Burnett" wrote:
>
>> Postgres Version 8.25
>
> Do you mean 8.2.5? (There is no PostgreSQL version 8.25.)
>
Yeah, missed a '.', it's 8.2.5
> If you're concerned about perfo
So, building the partial index will avoid the table lookup.
Currently answerselectindex only has single-column indexes on memberid and
answerid, so any query with a predicate on both columns is gonna be forced to
do an index lookup on one column followed by a table lookup to get the other
one (w
"Kevin Grittner" writes:
> By the way, 8.0 is going out of support as soon as the 9.0 release
> comes out; likely next month.
Small clarification on that: the plan is that there will be exactly
one more minor update of 8.0 (and 7.4). So it'll go out of support
after the next set of back-branch u
"Kevin Grittner" wrote:
> "Aaron Burnett" wrote:
>> Postgres Version 8.25
>
> Do you mean 8.2.5? (There is no PostgreSQL version 8.25.)
I just noticed that there's an 8.0.25 -- if that's what you're
running, it's a bit silly trying to optimize individual slow queries
-- performance has im
Here's a quote from the docs:
To combine multiple indexes, the system scans each needed index and prepares a
bitmap in memory giving the locations of table rows that are reported as
matching that index's conditions. The bitmaps are then ANDed and ORed together
as needed by the query. Finally,
> without ORDER BY database returns first 15 rows where predicate is
> true. With ORDER BY the database has to find all rows where predicate
> is true and then has to sort it. So first case can be a much faster
> because there are not necessary full table scan.
Right. Essentialy, the ORDER BY happ
Excerpts from Tom Lane's message of lun ago 16 23:33:29 -0400 2010:
> "Benjamin Krajmalnik" writes:
> > A little background - I have various multi-column indexes whenever I
> > have queries which restrict the output based on the values of the 2
> > fields (for example, a client code and the date o
"Aaron Burnett" wrote:
> Postgres Version 8.25
Do you mean 8.2.5? (There is no PostgreSQL version 8.25.)
If you're concerned about performance and you're still on 8.2, you
might want to consider updating to a new major version.
> 16 Gig RAM
> 192MB work_mem (increasing to 400MB didn't ch
Hello
2010/8/17 :
>
> Hi,
>
> I've database of lyrics and I'm using this query for suggest box.
> SELECT views, title, id FROM songs WHERE title ILIKE 'bey%' ORDER BY views
> DESC LIMIT 15;
> In query plan is this line: -> Seq Scan on songs (cost=0.00..11473.56
> rows=5055 width=23) (actual
On 17 August 2010 08:26, wrote:
>
> Hi,
>
> I've database of lyrics and I'm using this query for suggest box.
> SELECT views, title, id FROM songs WHERE title ILIKE 'bey%' ORDER BY views
> DESC LIMIT 15;
> In query plan is this line: -> Seq Scan on songs (cost=0.00..11473.56
> rows=5055 wid
Hi,
I've database of lyrics and I'm using this query for suggest box.
SELECT views, title, id FROM songs WHERE title ILIKE 'bey%' ORDER BY views
DESC LIMIT 15;
In query plan is this line: -> Seq Scan on songs (cost=0.00..11473.56
rows=5055 width=23) (actual time=1.088..89.863 rows=77 loops=
On Tuesday 17 August 2010 10:29:10 Greg Smith wrote:
> Andres Freund wrote:
> > An fsync() equals a barrier so it has the effect of stopping
> > reordering around it - especially on systems with larger multi-disk
> > arrays thats pretty expensive.
> > You can achieve surprising speedups, at least i
Bruce Momjian wrote:
Scott Carey wrote:
Don't ever have WAL and data on the same OS volume as ext3.
...
One partition for WAL, one for data. If using ext3 this is essentially
a performance requirement no matter how your array is set up underneath.
Do we need to document this?
No
Andres Freund wrote:
An fsync() equals a barrier so it has the effect of stopping
reordering around it - especially on systems with larger multi-disk
arrays thats pretty expensive.
You can achieve surprising speedups, at least in my experience, by
forcing the kernel to start writing out pages *wi
21 matches
Mail list logo
