r when i test the upgrade.
> In the past i was able to find the 2.2.2-1 version rpm for previous
> versions on postgres website but not this time for postgresql 9.5
>
>
>
> Thanks
> Avi
>
>
>
>
>
--
Jan Wieck
Senior Postgres Architect
On 12/6/2005 4:08 AM, Assaf Yaari wrote:
Thanks Bruno,
Issuing VACUUM FULL seems not to have influence on the time.
I've added to my script VACUUM ANALYZE every 100 UPDATE's and run the
test again (on different record) and the time still increase.
I think he meant
- run VACUUM FULL once,
On 12/4/2005 4:33 AM, Michael Riess wrote:
I will do the following:
- switch to 10k buffers on a 1GB machine, 20k buffers on a 2GB machine
- try to optimize my connection polls to remember which apps (groups of
30 tables) were accessed, so that there is a better chance of using caches
- swap
On 12/2/2005 6:01 PM, Michael Riess wrote:
Hi,
thanks for your comments so far - I appreciate it. I'd like to narrow
down my problem a bit:
As I said in the other thread, I estimate that only 20% of the 15,000
tables are accessed regularly. So I don't think that vacuuming or the
number of
On 12/3/2005 11:41 AM, Michael Riess wrote:
Alvaro Herrera schrieb:
Michael Riess wrote:
Shared memory ... I currently use 1500 buffers for 50 connections, and
performance really suffered when I used 3000 buffers. The problem is
that it is a 1GB machine, and Apache + Tomcat need about
On 12/1/2005 2:34 PM, Michael Riess wrote:
VACUUM FULL was probably always overkill, unless always includes
versions prior to 7.3...
Well, we tried switching to daily VACUUM ANALYZE and weekly VACUUM FULL,
but the database got considerably slower near the end of the week.
This indicates
On 10/27/2005 7:29 AM, Richard Huxton wrote:
Don't forget to CC the list
Svenne Krap wrote:
What do you mean exactly but pushing conditions inside ?
If I have something like SELECT * FROM complicated_view WHERE foo = 7
then the planner can look inside complicated_view and see where it can
On 6/6/2005 2:12 PM, PFC wrote:
Please pardon my ignorance, but from whatever I had heard, mysql was
supposedly always faster than postgres Thats why I was so surprised
!!
I heard a lot of this too, so much it seems common wisdom that postgres
is slow... well maybe some old version
On 3/14/2005 4:26 AM, Qingqing Zhou wrote:
So is it to make SQL parser context-sensitive - say the parser will
understand that in statement SELECT * from LIMIT, LIMIT is just a table
name, instead of keyword?
More or less, yes. To use a reserved keyword as an identifier (table or
column name), it
On 3/14/2005 1:28 PM, Robert Treat wrote:
Yeah... how come no one told him don't do that? LIMIT is an SQL
reserved word, so it's likely to cause trouble in any database you try
to use it on... I'd strongly recommend renaming that column asap. You
can see other reserved words at
On 3/14/2005 2:26 PM, Bryan Encina wrote:
Note also that the Slony-I replication system has problems
with column
names identical to reserved words. This is rooted in the fact
that the
quote_ident() function doesn't quote reserved words ... as it IMHO is
supposed to do.
Jan
Does this apply to
On 1/28/2005 2:49 PM, Christopher Browne wrote:
But there's nothing wrong with the idea of using pg_dump --data-only
against a subscriber node to get you the data without putting a load
on the origin. And then pulling the schema from the origin, which
oughtn't be terribly expensive there.
And
On 11/17/2004 5:07 PM, Josh Berkus wrote:
David,
I understand that the sort_mem conf setting affects queries with order by,
etc., and the doc mentions that it is used in create index. Does sort_mem
affect the updating of indexes, i.e., can the sort_mem setting affect the
performance of inserts?
On 10/13/2004 11:47 PM, Bruce Momjian wrote:
Josh Berkus wrote:
Aaron,
That makes two of us. Hanging out with Tom, Bruce, and others at OSCON
2002 was one of the most informative and fun times I've had. That and
I could really stand to brush up on my Postgres basics
You're thinking of Jan.
On 10/14/2004 6:36 PM, Simon Riggs wrote:
[...]
I think Jan has said this also in far fewer words, but I'll leave that to
Jan to agree/disagree...
I do agree. The total DB size has as little to do with the optimum
shared buffer cache size as the total available RAM of the machine.
After reading
On 10/14/2004 8:10 PM, Christopher Browne wrote:
Quoth [EMAIL PROTECTED] (Simon Riggs):
I say this: ARC in 8.0 PostgreSQL allows us to sensibly allocate as
large a shared_buffers cache as is required by the database
workload, and this should not be constrained to a small percentage
of server RAM.
Trying to think a little out of the box, how common is it in modern
operating systems to be able to swap out shared memory?
Maybe we're not using the ARC algorithm correctly after all. The ARC
algorithm does not consider the second level OS buffer cache in it's
design. Maybe the total size of
On 10/17/2004 3:40 PM, [EMAIL PROTECTED] wrote:
Seeing as I've missed the last N messages... I'll just reply to this
one, rather than each of them in turn...
Tom Lane [EMAIL PROTECTED] wrote on 16.10.2004, 18:54:17:
I wrote:
Josh Berkus writes:
First off, two test runs with OProfile are
On 10/9/2004 7:20 AM, Kevin Brown wrote:
Christopher Browne wrote:
Increasing the number of cache buffers _is_ likely to lead to some
slowdowns:
- Data that passes through the cache also passes through kernel
cache, so it's recorded twice, and read twice...
Even worse, memory that's used for
On 10/14/2004 12:22 AM, Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Which would require that shared memory is not allowed to be swapped out, and
that is allowed in Linux by default IIRC, not to completely distort the entire
test.
Well if it's getting swapped out then it's clearly
On 10/13/2004 11:52 PM, Greg Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 10/8/2004 10:10 PM, Christopher Browne wrote:
[EMAIL PROTECTED] (Josh Berkus) wrote:
I've been trying to peg the sweet spot for shared memory using
OSDL's equipment. With Jan's new ARC patch, I was expecting
On 8/24/2004 1:08 AM, my ho wrote:
--- Jan Wieck [EMAIL PROTECTED] wrote:
On 8/17/2004 8:44 PM, my thi ho wrote:
Hi,
I am working on a project which explore postgresql
to
store multimedia data.
In details, i am trying to work with the buffer
management part of postgres source code. And try
On 8/8/2004 8:10 AM, Jeff wrote:
On Aug 8, 2004, at 1:29 AM, Martin Foster wrote:
I am currently making use of Apache::DBI which overrides the
DBI::disconnect call and keeps a pool of active connections for use
when need be. Since it offloads the pooling to the webserver, it
seems more
On 8/3/2004 2:05 PM, Martin Foster wrote:
I run a Perl/CGI driven website that makes extensive use of PostgreSQL
(7.4.3) for everything from user information to formatting and display
of specific sections of the site. The server itself, is a dual
processor AMD Opteron 1.4Ghz w/ 2GB Ram and 2
On 7/12/2004 12:38 PM, Josh Berkus wrote:
Rond, Chris,
What would be most interesting to see is whether this makes it wise to
increase shared buffer size. It may be more effective to bump down
the cache a little, and bump up sort memory; hard to tell.
How do we go about scheduling tests with
On 7/9/2004 10:16 AM, Merlin Moncure wrote:
What is it about the buffer cache that makes it so unhappy being able
to
hold everything? I don't want to be seen as a cache hit fascist, but
isn't
it just better if the data is just *there*, available in the
postmaster's
address space ready for each
Using VMware myself quite extensively, I wonder what the disk
configuration was that you created for the VM. Where the disks
preallocated and did you make sure that they are contiguous on the NTFS
filesystem? Did you install the VMware tools in the guest operating system?
What did you use to
| off
(113 rows)
suggestions, doubts and commentaries are very welcome
regards
__
Eduardo Cunha de Almeida
Administrao de Banco de Dados
UFPR - CCE
+55-41-361-3321
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--- Jan Wieck [EMAIL PROTECTED] wrote:
Josh Berkus wrote
Josh Berkus wrote:
Folks,
I've sent a polite e-mail to Mr. Gomez offering our help. Please, nobody
flame him!
Please keep in mind that the entire test has, other than a similar
database schema and query types maybe, nothing to do with a TPC-H. I
don't see any kind of SUT. Foreign key
Mike Nolan wrote:
Seriously, I am tired of this kind of question. You gotta get bold
enough to stand up in a meeting like that, say guy's, you can ask me
how this compares to Oracle ... but if you're seriously asking me how
this compares to MySQL, call me again when you've done your homework.
Josh Berkus wrote:
Folks,
I've had requests from a couple of businesses to see results of infomal MySQL
+InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do
full formal benchmarking, but surely someone in our community has gone
head-to-head on your own application?
Josh,
31 matches
Mail list logo
