On tor, 2010-06-17 at 18:28 -0400, Brant Fitzsimmons wrote:
> Performance has dropped through the floor after converting my db from
> ASCI to UTF8.
Converting from ASCII to UTF8 is a noop.
If you did some configuration changes, you need to tell us which.
--
Sent via pgsql-performance mailing l
On tis, 2009-11-17 at 11:36 -0500, Merlin Moncure wrote:
> I am right now talking to someone on postgresql irc who is measuring
> 15k iops from x25-e and no data loss following power plug test. I am
> becoming increasingly suspicious that peter's results are not
> representative: given that 90% of
On Monday 20 July 2009 04:46:53 Robert James wrote:
> I'm storing a lot of words in a database. What's the fastest format for
> finding them? I'm going to be doing a lot of WHERE w LIKE 'marsh%' and
> WHERE w IN ('m', 'ma'). All characters are lowercase a-z, no punctuation,
> no other alphabets.
On Friday 17 July 2009 16:40:40 Matthew Wakeling wrote:
> I'm considering rewriting a postgres extension (GiST index bioseg) to make
> it use version 1 calling conventions rather than version 0.
>
> Does anyone have any ideas/opinions/statistics on what the performance
> difference is between the t
Aidan Van Dyk wrote:
* Joshua D. Drake <[EMAIL PROTECTED]> [081209 11:01]:
Yes the SmartArray series is quite common and actually know to perform
reasonably well, in RAID 10. You still appear to be trying RAID 5.
*boggle*
Are people *still* using raid5?
/me gives up!
What do you sugges
Peter Childs wrote:
I have a problem where by an insert on a "large" table will sometimes
take longer than usual.
I think the problem might have something to do with checkpoints,
Then show us your checkpointing-related parameters. Or try to set them
to a lot higher values so checkpoints ha
Axel Rau wrote:
Im not yet convinced to switch to non-C locale. Is the following
intended behavior:
With lc_ctype C: select lower('ÄÖÜ'); => ÄÖÜ
With lc_ctype en_US.utf8 select lower('ÆÅË'); => æåë
? (Both have server encoding UTF8)
I would expect exactly that.
--
Sent via pgsql-p
Axel Rau wrote:
some erp software requires a change of my pgsql cluster from
locale Cencoding UTF-8
to
locale de_DE.UTF-8encoding UTF-8
Most of my databases have only ASCII text data (8 bit UTF8 code range)
in the text columns.
Does the above change influence index performa
Dan Harris wrote:
> My desire would be to have a parallel server that could act as a hot
> standby system with automatic fail over in a multi-master role.
I will add my "me too" for DRBD + Heartbeat.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
Laszlo Nagy wrote:
> Question 1. We are going to use PostgreSQL 3.1 with FreeBSD. The pg docs
> say that it is better to use FreeBSD because it can alter the I/O
> priority of processes dynamically.
Where does it say that?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.
Vinubalaji Gopal wrote:
> I tried using the nice command (Linux system) on the maintenance script
> - it did not have any effect - guess it does not change the niceness of
> the postgresql vacuum process.
You are probably looking for the command ionice. nice only affects the CPU
priority, and th
ks cache space is oversubscribed nearly 3X when in reality
> the database is fully cached.
I should add that other, similar queries in this database that do not involve
joining the same table twice produce seemingly optimal plans. (It picks hash
joins which are actually faster than neste
o go that far.
Heh, when I decrease these parameters, the hash join gets cheaper as well. I
can't actually get it to pick the nested-loop join.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4:
Cond: ((email.email_id = eh_subj.email_id) AND (0 =
eh_subj.mime_part_id))
Filter: (header_name = 'subject'::text)
Total runtime: 5161.390 ms
> Are you using any nondefault planner settings?
random_page_cost = 3
effective_cache_size = 384MB
> How big are th
Am Mittwoch, 9. Mai 2007 16:29 schrieb Alvaro Herrera:
> Peter Eisentraut wrote:
> > There's another odd thing about this plan from yesterday.
>
> Is this still 8.2.1? The logic to choose bitmap indexes was rewritten
> just before 8.2.4,
OK, upgrading to 8.2.4 fixes thi
n all
of them have the same predicate and none of them has an indexed
expression that appears in the query?
There are more partial indexes with the same predicate, but it appears
to always use three. (The two "dummy" indexes are just leftovers from
these experiments.)
--
Peter Eisentraut
ht
effects are much more significant than the
model takes into account.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://ww
ation.
Most likely, all of these database is cached, so I tried reducing
seq_page_cost and random_page_cost, but I needed to turn them all the way
down to 0.02 or 0.03, which is almost like cpu_tuple_cost. Is that
reasonable? Or what is wrong here?
PostgreSQL 8.2.1 on x86_64-unknown-li
ies.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
nothing to do with performance, I gather, so it might be more
appropriate for the pgsql-sql list.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
poor startup time.
So from when to when is the startup time (the "x" in "x..y") actually
measured? When does the clock start ticking and when does it stop?
That is what's confusing me.
--
Peter Eisentraut
http://developer.postgresql.org/~petere
ds to scan all
> those records before it founds 100 it can output. This is the “startup
> cost” you're seeing.
The startup cost is the cost until the plan is set up to start outputting
rows. It is not the time until the first row is found.
--
Peter Eisentraut
http://develop
Am Donnerstag, 30. März 2006 14:06 schrieb Michael Stone:
> On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
> >The table has seen VACUUM FULL and REINDEX before this.
>
> But no analyze?
ANALYZE as well, but the plan choice is not the point anyway.
--
Peter
Am Donnerstag, 30. März 2006 14:02 schrieb Steinar H. Gunderson:
> On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
> > EXPLAIN ANALYZE select activity_id from activity where state in (1,
> > 10001) order by activity_id limit 100;
> >
> > QUERY PLA
so it's not just a case of a
temporary I/O bottleneck, say.
(PostgreSQL 8.0.3)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
but
> > you can fsync less often and thus be faster" (with a possibility of
> > setting that on a per-table basis) ?
Then it would be "ACI" compliant.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
hat had in mind:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/template/freebsd.diff?r1=1.10&r2=1.11
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
karounds for sloppy Apple engineering.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
d
> I should retunr faster than the first time.
What happens the third time?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
29 matches
Mail list logo
