Can you tell us more about the structure of your
tables,
witch sort of index did you set on witch fields
?
Did you really need to get ALL records at
once, instead you may be could use paging
(cursor or SELECT LIMIT OFFSET ) ?
And did you well
configure your .conf ?
Regards
Alban
M
Igor Maciel Macaubas wrote:
Hi all,
I'm trying to find smarter ways to dig data from my database, and
have the following scenario:
table1 -- id -- name . . . . . .
table2 -- id -- number . . . . . .
I want to create a view to give me back just what I want: The id, the
name and the number. I tought
>Timothy D. Witham
> On Thu, 2004-10-14 at 16:57 -0700, Josh Berkus wrote:
> > Simon,
> >
> >
> >
> > > If you draw a graph of speedup (y) against cache size as a
> > > % of total database size, the graph looks like an upside-down
> "L" - i.e.
> > > the graph rises steeply as you give it more memo
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > Hmm...something just occurred to me about this.
>
> > Would a hybrid approach be possible? That is, use mmap() to handle
> > reads, and use write() to handle writes?
>
> Nope. Have you read the specs regarding mmap-vs-stdio synchroni
Hi,
we are working on a product which was originally developed against an Oracle
database and which should be changed to also work with postgres.
Overall the changes we had to make are very small and we are very pleased with
the good performance of postgres - but we also found queries which ex
> SELECT cmp.WELL_INDEX, cmp.COMPOUND, con.CONCENTRATION
> FROM SCR_WELL_COMPOUND cmp, SCR_WELL_CONCENTRATION con
> WHERE cmp.BARCODE=con.BARCODE
> AND cmp.WELL_INDEX=con.WELL_INDEX
> AND cmp.MAT_ID=con.MAT_ID
> AND cmp.MAT_ID = 3
>
But he's testing with v8 beta3, so you'd expect the typecast problem not to appear?
Are all tables fully vacuumed? Should the statistics-target be raised for some
columns, perhaps? What about the config file?
--Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Beh
Tom Lane wrote:
Kevin Brown <[EMAIL PROTECTED]> writes:
Hmm...something just occurred to me about this.
Would a hybrid approach be possible? That is, use mmap() to handle
reads, and use write() to handle writes?
Nope. Have you read the specs regarding mmap-vs-stdio synchronization?
B
> 2/ Batch-inserts using jdbc (maybe this should go to the jdbc-mailing
list -
> but it is also performance related ...):
> Performing many inserts using a PreparedStatement and batch execution
makes a
> significant performance improvement in Oracle. In postgres, I did not
observe
> any performa
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> So are we correct to rely on
> - 8 being slower than 7.x in general and
I think this is a highly unlikely claim ... *especially* if you are
comparing against 7.1. The point about sync() being a no-op is real,
but offhand I think it would only come
Hello,
I've seen a couple references to using ipcs to help properly size
shared_buffers.
I don't claim to be a SA guru, so could someone help explain how to
interpret the output of ipcs and how that relates to shared_buffers? How
does one determine the size of the segment arrays? I see the tota
> Thanks Magnus,
>
> So are we correct to rely on
> - 8 being slower than 7.x in general and
> - 8 on Win32 being a little faster than 8 on Cygwin?
>
> Will the final release of 8 be faster than the beta?
I'm pretty certain that previous to 8.0 no win32 based postgesql
properly sync()ed the file
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Speculating wildly because I don't know that portion of the code this might
> be:
> CONJECTURE 1: the act of searching for a block in cache is an O(n)
> operation, not an O(1) or O(log n) operation
I'm not sure how this meme got into circulation, but I'v
My basic question to the community is "is PostgreSQL approximately as fast
as Oracle?"
I don't want benchmarks, they're BS. I want a gut feel from this community
because I know many of you are in mixed shops that run both products, or
have had experience with both.
I fully intend to tune, vacuum
Tom Lane wrote:
> > I've been thinking about implementing a scheme that helps you decide how
> > big the shared_buffers SHOULD BE, by making the LRU list bigger than the
> > cache itself, so you'd be able to see whether there is beneficial effect in
> > increasing shared_buffers.
>
> ARC already k
[EMAIL PROTECTED] wrote:
> My basic question to the community is "is PostgreSQL approximately as fast
> as Oracle?"
>
> I don't want benchmarks, they're BS. I want a gut feel from this community
> because I know many of you are in mixed shops that run both products, or
> have had experience with
Bernd <[EMAIL PROTECTED]> writes:
> 1/ The following query takes about 5 sec. with postrgres whereas on Oracle it
> executes in about 30 ms (although both tables only contain 200 k records in
> the postgres version).
What does EXPLAIN ANALYZE have to say about it? Have you ANALYZEd the
tables in
On Fri, Oct 15, 2004 at 11:54:44AM -0500, [EMAIL PROTECTED] wrote:
> My basic question to the community is "is PostgreSQL approximately as fast
> as Oracle?"
> I'm currently running single processor UltraSPARC workstations, and intend
> to use Intel Arch laptops and Linux. The application is a bi
Doug Y <[EMAIL PROTECTED]> writes:
> I've seen a couple references to using ipcs to help properly size
> shared_buffers.
I have not seen any such claim, and I do not see any way offhand that
ipcs could help.
> I tried all of the dash commands in the ipcs man page, and the only one
> that might
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I'm pretty certain that previous to 8.0 no win32 based postgesql
> properly sync()ed the files. Win32 does not have sync(), and it is
> impossible to emulate it without relying on the application to track
> which files to sync. 8.0 does this because
[EMAIL PROTECTED] writes:
> My basic question to the community is "is PostgreSQL approximately as fast
> as Oracle?"
The anecdotal evidence I've seen leaves me with the impression that when
you first take an Oracle-based app and drop it into Postgres, it won't
perform particularly well, but with t
On Fri, 15 Oct 2004 11:54:44 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> My basic question to the community is "is PostgreSQL approximately as fast
> as Oracle?"
>
> I don't want benchmarks, they're BS. I want a gut feel from this community
> because I know many of you are in mixed shop
Tom Lane wrote:
Doug Y <[EMAIL PROTECTED]> writes:
I've seen a couple references to using ipcs to help properly size
shared_buffers.
I have not seen any such claim, and I do not see any way offhand that
ipcs could help.
Directly from:
http://www.varlena.com/varlena/GeneralBits/Tidbits/a
> Bruce Momjian
> Tom Lane wrote:
> > > I've been thinking about implementing a scheme that helps you
> decide how
> > > big the shared_buffers SHOULD BE, by making the LRU list
> bigger than the
> > > cache itself, so you'd be able to see whether there is
> beneficial effect in
> > > increasing sh
People:
> First off, many thanks for taking the time to provide the real detail on
> the code.
>
> That gives us some much needed direction in interpreting the oprofile
> output.
I have some oProfile output; however, it's in 2 out of 20 tests I ran recently
and I need to get them sorted out.
--
On Fri, 15 Oct 2004 11:54:44 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> My basic question to the community is "is PostgreSQL approximately as fast
> as Oracle?"
My personal experience comparing PG to Oracle is across platforms,
Oracle on Sun/Solaris (2.7, quad-proc R440) and PG on Intel
Doug Y <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I have not seen any such claim, and I do not see any way offhand that
>> ipcs could help.
>>
> Directly from:
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
> "As a rule of thumb, observe shared memory usage of Pos
pg to my mind is unique in not trying to avoid OS buffering. Other
dbmses spend a substantial effort to create a virtual OS (task
management, I/O drivers, etc.) both in code and support. Choosing mmap
seems such a limiting an option - it adds OS dependency and limits
kernel developer options (2G li
Tom, Simon:
First off, two test runs with OProfile are available at:
http://khack.osdl.org/stp/298124/
http://khack.osdl.org/stp/298121/
> AtEOXact_Buffers
> transaction commit or abort
> UnlockBuffers
> transaction abort, backend exit
Actually, this might explain the "hump" shap
this. The SUS text is a bit weaselly ("the application must ensure
correct synchronization") but the HPUX mmap man page, among others,
lays it on the line:
It is also unspecified whether write references to a memory region
mapped with MAP_SHARED are visible to processes reading the file
Josh Berkus <[EMAIL PROTECTED]> writes:
> First off, two test runs with OProfile are available at:
> http://khack.osdl.org/stp/298124/
> http://khack.osdl.org/stp/298121/
Hmm. The stuff above 1% in the first of these is
Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit
Tom,
> I suspect the reason recalc_sigpending_tsk is so high is that the
> original coding of PG_TRY involved saving and restoring the signal mask,
> which led to a whole lot of sigsetmask-type kernel calls. Is this test
> with beta3, or something older?
Beta3, *without* Gavin or Neil's Futex pa
On Fri, Oct 15, 2004 at 01:09:01PM -0700, Sean Chittenden wrote:
[snip]
> >
> > This ultimately depends on two things: how much time is spent copying
> > buffers around in kernel memory, and how much advantage can be gained
> > by freeing up the memory used by the backends to store the
> > backend-
Tom Lane wrote:
Doug Y <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This might tell you something about how many concurrent backends you've
used, but nothing about how many shared buffers you need.
Thats strange, I know I've had more than 4 concurrent connections on
that box... (I ju
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Coordination of data isn't
> necessary if you mmap(2) data as a private block, which takes a
> snapshot of the page at the time you make the mmap(2) call and gets
> copied only when the page is written to. More on that later.
We cannot move to a mo
Josh Berkus <[EMAIL PROTECTED]> writes:
>> I suspect the reason recalc_sigpending_tsk is so high is that the
>> original coding of PG_TRY involved saving and restoring the signal mask,
>> which led to a whole lot of sigsetmask-type kernel calls. Is this test
>> with beta3, or something older?
> B
On Fri, Oct 15, 2004 at 05:27:29PM -0400, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> >> I suspect the reason recalc_sigpending_tsk is so high is that the
> >> original coding of PG_TRY involved saving and restoring the signal mask,
> >> which led to a whole lot of sigsetmask-type k
Mark Wong <[EMAIL PROTECTED]> writes:
> I know where the do_sigaction is coming from in this particular case.
> Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
> Commenting out those two calls out virtually eliminates do_sigaction from
> the kernel profile for this workload.
Hmm, I
Mark Wong <[EMAIL PROTECTED]> writes:
> On Fri, Oct 15, 2004 at 05:27:29PM -0400, Tom Lane wrote:
>> Hmm, in that case the cost deserves some further investigation. Can we
>> find out just what that routine does and where it's being called from?
> There's a call-graph feature with oprofile as of
On Fri, Oct 15, 2004 at 05:37:50PM -0400, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > I know where the do_sigaction is coming from in this particular case.
> > Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
> > Commenting out those two calls out virtually eliminates
On Fri, Oct 15, 2004 at 05:44:34PM -0400, Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > On Fri, Oct 15, 2004 at 05:27:29PM -0400, Tom Lane wrote:
> >> Hmm, in that case the cost deserves some further investigation. Can we
> >> find out just what that routine does and where it's being
On Tue, 12 Oct 2004, Stef wrote:
> Pierre-Frédéric Caillaud mentioned :
> => http://www.postgresql.org/docs/7.4/static/jdbc-query.html#AEN24298
>
> My question is :
> Is this only true for postgres versions >= 7.4 ?
>
> I see the same section about "Setting fetch size to turn cursors on and of
Tom Lane wrote:
> Mark Wong <[EMAIL PROTECTED]> writes:
> > I know where the do_sigaction is coming from in this particular case.
> > Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
> > Commenting out those two calls out virtually eliminates do_sigaction from
> > the kernel profile
43 matches
Mail list logo
