Am Montag, 7. November 2005 18:22 schrieb PostgreSQL:
> My most humble apologies to the pg development team (pg_lets?).
>
> I took Greg Stark's advice and set:
>
> shared_buffers = 1 # was 5
> work_mem = 1048576# 1Gb - was 16384
>
> Also, I noticed that the EXPLAIN ANALYZE consistently
gards,
Mario Weilguni
Am Freitag, 23. Dezember 2005 13:34 schrieb Carlos Benkendorf:
> Hi,
>
> We have more than 200 customers running 8.0.3 and two weeks ago started
> migration project to 8.1.1.After the first migration to 8.1.1 we had to
> return back to 8.0.3 because some a
Am Donnerstag, 22. März 2007 12:30 schrieb [EMAIL PROTECTED]:
> approximated count?
>
> why? who would need it? where you can use it?
>
> calculating costs and desiding how to execute query needs
> approximated count, but it's totally worthless information for any user
> IMO.
No, it is not use
Am Donnerstag, 22. März 2007 15:33 schrieb Jonah H. Harris:
> On 3/22/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > As others suggest select count(*) from table is very special case
> > which non-mvcc databases can optimize for.
>
> Well, other MVCC database still do it faster than we do. Howe
Am Donnerstag, 22. März 2007 16:17 schrieb Andreas Kostyrka:
> * Mario Weilguni <[EMAIL PROTECTED]> [070322 15:59]:
> > Am Donnerstag, 22. März 2007 15:33 schrieb Jonah H. Harris:
> > > On 3/22/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > > > As ot
um' as frequently as every 15-30 minutes?
No problem.
>
> 4. Suggestions?
Do yourself a favor and upgrade at least to 8.1.x and use autovacuum.
Best regards
Mario Weilguni
---(end of broadcast)---
TIP 6: explain analyze is your friend
Am Freitag 13 Juli 2007 schrieb smiley2211:
> Hello all,
>
> I am a bit confused...I have a database which was performing very POORLY
> selecting from a view (posted earlier) on one server but extremely fast on
> another server...
>
> I just backed up the database from the FAST server and loaded to
Am Dienstag 24 Juli 2007 schrieb Tom Lane:
> > I thought the
> > to_char/to_date/to_timestamp functions were intented for this purposes
>
> No, they're intended for dealing with wacky formats that the regular
> input/output routines can't understand or produce.
Really? I use them alot, because of
Am Mittwoch 25 Juli 2007 schrieb Simon Riggs:
> I have reasonable evidence that Referential Integrity is the major
> performance bottleneck and would like some objective evidence that this
> is the case.
Just curious, will 8.3 still check FK constraints (and use locks) even if the
referencing col
Simon Riggs schrieb:
On Fri, 2007-09-07 at 11:37 +0200, Maila Fatticcioni wrote:
protocol C;
Try protocol B instead.
Sure? I've always heard that there has yet to be a case found, where B
is better than C. We use DRBD with protocol C, and are quite happy with it.
--
Fernan Aguero schrieb:
Hi,
I have a table containing some ~13 million rows. Queries on
indexed fields run fast, but unanchored pattern queries on a
text column are slow. Indexing the column doesn't help
(this is already mentioned in the manual).
http://www.postgresql.org/docs/8.2/interactive
Am 03.02.2011 00:15, schrieb Dan Birken:
I'm setting up a dedicated linux postgres box with 2x300GB 15k SAS
drive in a RAID 1, though if future load dictates we would like to be
able to upgrade to RAID 10. The hosting provider offers the following
options for a RAID controller (all are the sam
Am Donnerstag, 26. Januar 2006 11:06 schrieb Paul Mackay:
> Hi,
>
> I've created a table like this :
> CREATE TABLE tmp_A (
> c "char",
> i int4
> );
>
> And another one
> CREATE TABLE tmp_B (
> i int4,
> ii int4
> );
>
> I then inerted a bit more than 19 million rows in each table (exactly the
> s
Am Sonntag, 2. Juli 2006 23:50 schrieb Gene:
> Is there any way to create a reverse index on string columns so that
> queries of the form:
>
> where column like '%2345';
>
> can use an index and perform as fast as searching with like '2345%'?
>
> Is the only way to create a reverse function and cre
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
> Lastly, note that in PostgreSQL these length declarations are not
> necessary:
>
> contacto varchar(255),
> fuente varchar(512),
> prefijopais varchar(10)
>
> Instead, use:
>
> contacto text,
> fuente text,
> prefij
Am Dienstag, 17. Oktober 2006 17:50 schrieb Alexander Staubo:
> On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:
> >
> > Enforcing length constraints with varchar(xyz) is good database
> > design, not a
> > bad one. Using text everywhere might be tempting because it wo
management system), and the performance of
the 32k variants is slightly better for a few queries, overall responsivness
seems to better with 8k (maybe because the 8k variant has 4x more buffers).
Regards,
Mario Weilguni
---(end of broadcast)---
TIP
Am Donnerstag, 10. März 2005 08:44 schrieb Karim Nassar:
> From rom http://www.powerpostgresql.com/PerfList/
>
> "even in a two-disk server, you can put the transaction log onto the
> operating system disk and reap some benefits."
>
> Context: I have a two disk server that is about to become dedica
Jean-David Beyer schrieb:
I am doing lots of INSERTs on a table that starts out empty (I did a
TRUNCATE on it). I am not, AFAIK, doing DELETEs or UPDATEs. Autovacuum is
on. I moved logging up to debug2 level to see what was going on, and I get
things like this:
"vl_as": scanned 3000 of 5296 pag
g_attribute_relid_attnum_index on
pg_attribute a (cost=0.00..4.27 rows=1 width=70) (actual
time=0.006..0.007 rows=1 loops=4020)
Index Cond: ((ss.roid = a.attrelid) AND (a.attnum =
(ss.x).x))
Filter: (NOT attisdropped)
Total runtime: 30346.174 ms
(60 rows)
X-AntiVirus: checked by AntiVir MailGuard (Version: 8.0.0.18; AVE: 8.1.0.37;
VDF: 7.0.3.243)
This is Postgresql 8.2.4, on a Dual-Core XEON 3.6GHz. With nested_loops
off, I get a very fast response (330ms).
Regards,
Mario Weilguni
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Ow Mun Heng schrieb:
Is there any quick hacks to do this quickly? There's around
20-30million
rows of data.
I want to change a column type from varchar(4) to varchar()
table size is ~10-15GB (and another 10-15G for indexes)
What would be the preferrred way of doing it? SHould I be dropping t
Ow Mun Heng schrieb:
On Thu, 2008-07-10 at 09:57 -0400, Alvaro Herrera wrote:
Ow Mun Heng wrote:
This is what I see on the table
NEW attypmod = -1
OLD attypmod = 8
8 means varchar(4) which is what you said you had (4+4)
-1 means unlimited size.
This is cool.
If it
Andreas Hartmann schrieb:
Mario Weilguni schrieb:
Andreas Hartmann schrieb:
[…]
I just verified that the autovacuum property is enabled.
[…]
Did you have:
stats_start_collector = on
stats_block_level = on
stats_row_level = on
Otherwise autovacuum won't run IMO.
Thanks for the
Mark Kirkwood schrieb:
Mark Kirkwood wrote:
You are right, it does (I may be recalling performance from my other
machine that has a 3Ware card - this was a couple of years ago...)
Anyway, I'm thinking for the Hardware raid tests they may need to be
specified.
FWIW - of course this somewha
Valentin Bogdanov schrieb:
--- On Mon, 11/8/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
From: Gregory Stark <[EMAIL PROTECTED]>
Subject: Re: [PERFORM] Using PK value as a String
To: "Jay" <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
"Jay"
Andrus schrieb:
Richard,
These are the same but the times are different. I'd be very surprised if
you can reproduce these times reliably.
I re-tried today again and got same results: in production database
pattern query is many times slower that equality query.
toode and rid base contain o
Kevin Kempter schrieb:
Hi All;
I'm looking for tips / ideas per performance tuning some specific queries.
These are generally large tables on a highly active OLTP system
(100,000 - 200,000 plus queries per day)
First off, any thoughts per tuning inserts into large tables. I have a large
tab
Tom Lane schrieb:
"=?iso-8859-1?Q?Vegard_B=F8nes?=" <[EMAIL PROTECTED]> writes:
Running VACUUM VERBOSE pg_largeobject took quite some time. Here's the
output:
INFO: vacuuming "pg_catalog.pg_largeobject"
INFO: index "pg_largeobject_loid_pn_index" now contains 11060658 row
versions
Has anyone benchmarked this controller (PCIe/4x, 512 MB BBC)? We try to
use it with 8x SATA 1TB drives in RAID-5 mode under Linux, and measure
strange values. An individual drive is capable of delivering 91 MB/sec
sequential read performance, and we get values ~102MB/sec out of a
8-drive RAID5,
Scott Marlowe schrieb:
On Tue, Dec 2, 2008 at 2:22 AM, Mario Weilguni <[EMAIL PROTECTED]> wrote:
Has anyone benchmarked this controller (PCIe/4x, 512 MB BBC)? We try to use
it with 8x SATA 1TB drives in RAID-5 mode under Linux, and measure strange
values. An individual drive is capa
Kevin Grittner schrieb:
Mario Weilguni <[EMAIL PROTECTED]> wrote:
Has anyone benchmarked this controller (PCIe/4x, 512 MB BBC)? We try
to
use it with 8x SATA 1TB drives in RAID-5 mode under Linux, and
measure
strange values. An individual drive is capa
Alan Hodgson schrieb:
Mario Weilguni <[EMAIL PROTECTED]> wrote:
strange values. An individual drive is capable of delivering 91
MB/sec
sequential read performance, and we get values ~102MB/sec out of a
8-drive RAID5, seems to be ridiculous slow.
What command a
Scott Marlowe schrieb:
On Tue, Dec 9, 2008 at 5:17 AM, Mario Weilguni <[EMAIL PROTECTED]> wrote:
Alan Hodgson schrieb:
Mario Weilguni <[EMAIL PROTECTED]> wrote:
strange values. An individual drive is capable of delivering 91
MB/sec
sequential read perf
Aidan Van Dyk schrieb:
* 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!
Why
Scott Marlowe schrieb:
On Wed, Dec 10, 2008 at 12:45 AM, Mario Weilguni <[EMAIL PROTECTED]> wrote:
A customer of us uses the P400 on a different machine, 8 SAS drives (Raid 5
as well), and the performance is very, very good. So we thought it's a good
choice. Maybe the SATA dri
Aidan Van Dyk schrieb:
* Mario Weilguni <[EMAIL PROTECTED]> [081210 07:31]:
Why not? I know it's not performing as good as RAID-10, but it does not
waste 50% diskspace. RAID-6 is no option, because the performance is
even worse. And, on another system with RAID-5 + spare and
Am Donnerstag, 23. Oktober 2003 01:32 schrieb Rob Nagler:
> The concept of vacuuming seems to be problematic. I'm not sure why
> the database simply can't garbage collect incrementally. AGC is very
> tricky, especially AGC that involves gigabytes of data on disk.
> Incremental garbage collection
Am Donnerstag, 23. Oktober 2003 15:26 schrieb Tom Lane:
> ... if all tuples are the same size, and if you never have any
> transactions that touch enough tuples to overflow your undo segment
> (or even just sit there for a long time, preventing you from recycling
> undo-log space; this is the dual
Am 02.11.2011 08:12, schrieb Mohamed Hashim:
Dear All
Thanks for your suggestions & replies.
The below are the sample query which i put for particular one bill_id
EXPLAIN ANALYZE SELECT abd.bill_no as
bill_no,to_char(abd.bill_date,'dd/mm/') AS date,mp.product_desc as
product_desc,std.qua
Am 03.11.2011 17:08, schrieb Tomas Vondra:
On 3 Listopad 2011, 16:02, Mario Weilguni wrote:
No doubt about that, querying tables using conditions on array columns is
not the best direction in most cases, especially when those tables are
huge.
Still, the interesting part here is that the OP
Am 08.11.2011 13:15, schrieb Mohamed Hashim:
Hi Sam,Tomas
In my first post i have mentioned all how much shared (shared buffers,
effective cache size, work mem, etc.) and my OS and hardware
information and what are the basic settings i have changed
and regarding Explain analyze i gave one sa
Am 15.11.2011 01:42, schrieb Cody Caughlan:
We have anywhere from 60-80 background worker processes connecting to
Postgres, performing a short task and then disconnecting. The lifetime
of these tasks averages 1-3 seconds.
I know that there is some connection overhead to Postgres, but I dont
know
Am 23.12.2011 08:05, schrieb Scott Marlowe:
On Thu, Dec 22, 2011 at 11:18 PM, tuanhoanganh wrote:
Thanks for your answer. But how performance between raid5 and one disk.
One disk will usually win, 2 disks (in a mirror) will definitely win.
RAID-5 has the highest overhead and the poorest perfor
Am 13.01.2012 13:08, schrieb Anibal David Acosta:
Hi,
yesterday I delete about 200 million rows of a table (about 150GB of
data), after delete completes the autovacuum process start.
The autovacuum is running for about 11 hours but no space is released
Autovacuum parameters are with default
44 matches
Mail list logo
