into more and more.
Thanks for you time.
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on performance.
https://github.com/postwait/postgres/commit/c8f5a346c7b2c3eba9f72ea49077dc72f03a2679
Thoughts? Feedback?
As can be seen, the patch is pretty tiny.
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
in
things like: 1.23 turning into 1.2300 in the numeric returned. This are
significantly faster (as expected) than the type - string - numeric
conversions.
On Mar 3, 2010, at 5:01 AM, Yeb Havinga wrote:
Theo Schlossnagle wrote:
I didn't look deeply at the postgres internals to see
On Mar 1, 2010, at 4:35 PM, Tom Lane wrote:
Theo Schlossnagle je...@omniti.com writes:
I'm writing some extension and I have a hot code path that has a lot of
double (C type) data and needs to output NUMERIC tuple data. The current
methods I can find in the code to convert sprintf
my stuff and I'm spending
(wasting) all my time in that conversion. Is there a more efficient method of
converting a double into a postgres numeric value?
Best regards,
Theo
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
--
Sent via pgsql-hackers mailing list (pgsql-hackers
handler fires, I
detect whether the txn was committed or rolledback and rightly mark my work as
committed or rolled back.
Thoughts?
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201 f: +1.410.872.4911
--
Sent via pgsql-hackers mailing list (pgsql-hackers
that there was a better place to probe that
would be more comprehensive -- that should be addressed.
--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Jul 11, 2009, at 6:50 AM, Greg Stark wrote:
On Sat, Jul 11, 2009 at 6:17 AM, Theo Schlossnagleje...@omniti.com
wrote:
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle je...@omniti.com writes:
I would think it would be txns that would be reading that table,
but
I'm
there? I'm thinking it should be more selective about vxids it
chooses to block on. I'd expect it to block on vxids touching the
same table only.
Thoughts?
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201 f: +1.410.872.4911
--
Sent via pgsql-hackers
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle je...@omniti.com writes:
I would think it would be txns that would be reading that table, but
I'm thinking it is a bit to aggressive. Am I reading the code wrong
there? I'm thinking it should be more selective about vxids
to disk
I/O to be induced.
--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
else:
https://labs.omniti.com/trac/project-dtrace/wiki/Applications#PostgreSQL
Best regards,
Theo
--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
to mount
elsewhere on attached to the same SAN. Many confuse this for being
free. Regardless of how the snap is taken you have to pay for it..
either at snap time, at read time or at release time. Nothing's free.
// Theo Schlossnagle
// [EMAIL PROTECTED]: http://omniti.com
// Esoteric Curio
of at
least a week changes.
You're living in a dream world. Do you know any Oracle DBs who keep
enough rollback segments to go back a week?
Ours go for a good 6 hours sometimes :-D
// Theo Schlossnagle
// Esoteric Curio: http://www.lethargy.org/~jesus/
---(end
of the moon, let me know.
Integrated, native XML support can only help PostgreSQL. IMO, I want
this in core.
Agreed. In the server would be more useful to more people I think.
It would be really convenient to be able to have no effort XML
results sets to queries.
// Theo Schlossnagle
// [EMAIL
) is
obviated. In fact, as you can't guarantee the synchronicity means
that it can be confusing -- one expects a time-based clock to be
accurate to the time. A counter-based clock has no such expectations.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting
On Feb 4, 2007, at 1:36 PM, Jan Wieck wrote:
On 2/4/2007 10:53 AM, Theo Schlossnagle wrote:
As the clock must be incremented clusterwide, the need for it to
be insync with the system clock (on any or all of the systems)
is obviated. In fact, as you can't guarantee the synchronicity
timestamp. As such, any algorithms that use
lamport timestamps as a basis or assumption for the proof of their
correctness will not translate (provably) to this system.
How are your counter semantically equivalent to Lamport timestamps?
// Theo Schlossnagle
// CTO -- http://www.omniti.com
On Feb 3, 2007, at 4:38 PM, Jan Wieck wrote:
On 2/3/2007 4:05 PM, Theo Schlossnagle wrote:
On Feb 3, 2007, at 3:52 PM, Jan Wieck wrote:
On 2/1/2007 11:23 PM, Jim Nasby wrote:
On Jan 25, 2007, at 6:16 PM, Jan Wieck wrote:
If a per database configurable tslog_priority is given
On Feb 3, 2007, at 5:09 PM, Jan Wieck wrote:
On 2/3/2007 4:58 PM, Theo Schlossnagle wrote:
I don't have any such paper and the proof of concept will be the
implementation of the system. I do however see enough resistance
against this proposal to withdraw the commit timestamp
of replication design
hasn't happened, but I didn't see it referenced anywhere in this
thread. Can you point me to it? I've reviewed many of these papers
and would like to better understand what you are aiming at.
Best regards,
Theo Schlossnagle
---(end of broadcast
there -- I know its pros and cons well.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast)---
TIP 6: explain analyze is your friend
that companies out there could rely on. Many
other certifying entities have the same approach.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast)---
TIP 9
On Jan 23, 2007, at 5:04 PM, Mark Kirkwood wrote:
Theo Schlossnagle wrote:
On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
Hello,
I did like to know what you think about the postgresql
certifications provided for
PostgreSQL CE http
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
that will have the most disagreement.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
)
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan
On Oct 21, 2006, at 3:12 PM, Simon Riggs wrote:
On Sat, 2006-10-21 at 09:00 -0400, Theo Schlossnagle wrote:
On Oct 21, 2006, at 6:08 AM, Martijn van Oosterhout wrote:
On Sat, Oct 21, 2006 at 10:37:51AM +0100, Simon Riggs wrote:
Turning off WAL is a difficult topic. Without it you have
On Oct 21, 2006, at 4:40 PM, Simon Riggs wrote:
On Sat, 2006-10-21 at 15:17 -0400, Theo Schlossnagle wrote:
On Oct 21, 2006, at 3:12 PM, Simon Riggs wrote:
On Sat, 2006-10-21 at 09:00 -0400, Theo Schlossnagle wrote:
On Oct 21, 2006, at 6:08 AM, Martijn van Oosterhout wrote:
On Sat, Oct
database NO LOGGING;
(NO LOGGING being the only part we're currently missing) Is something
like this possible?
Cheers ;-)
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast
On Oct 20, 2006, at 1:58 PM, Tom Lane wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
Is it possible to create tables in fashion that will not write info
to the WAL log -- knowingly and intentionally making them
unrecoverable?
Use temp tables?
temp tables won't work too well -- unless
On Oct 20, 2006, at 4:24 PM, Simon Riggs wrote:
On Fri, 2006-10-20 at 13:18 -0400, Theo Schlossnagle wrote:
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work
.) and in doing so,
you (1) spend the better part of a week running pg_restore and (2)
ANALYZE stats change, so your system's behavior changes in hard-to-
understand ways.
Best regards,
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http
On Oct 11, 2006, at 9:36 AM, Tom Lane wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
The real problem with a dump of the database is that you want to be
able to quickly switch back to a known working copy in the event of a
failure. A dump is the furthest possible thing from a working
fine
by the planner). To fix my one query, that is crucially important to
my business, it is a much more sane approach to hint the system to
change its plan than it is to have to upgrade my binaries.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting
What type of help did you envision? The answer is likely yes.
On Oct 11, 2006, at 5:02 PM, Josh Berkus wrote:
Theo,
Would you be able to help me, Zdenek Gavin in work on a new
pg_upgrade?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
// Theo Schlossnagle
// CTO -- http
On Oct 11, 2006, at 5:06 PM, Josh Berkus wrote:
What type of help did you envision? The answer is likely yes.
I don't know, whatever you have available. Design advice, at the very
least.
Absolutely. I might be able to contribute some coding time as well.
Testing time too.
// Theo
). I'd imagine that if the
above wasn't done cleverly, that performance problem would be repeated.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---(end of broadcast
to the suitability as general solution and as the
suitability for my acute issue (of a 5 million row setof returned
from that). Will it break anything?
Best regards,
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com
On Sep 14, 2006, at 7:03 AM, Gregory Stark wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
But the interesting thing is that there were 4.6 million elements
in the
s-childXids list. Which is why it took so damn long. I can't
quite figure
out how I induced this state. It is an OLAP
On Sep 14, 2006, at 8:19 AM, Gregory Stark wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
We don't use savepoint's too much. Maybe one or two across out 1k
or so
pl/pgsql procs.
Well if they're in a loop...
We use dbi-link which is plperl. Perhaps that is somehow creating
appropriate. Does the order of the
childXids chained off the current transaction state matter? Most of
the placed I could find that reference it seem to just attempt to
find an Xid in there. O(1) sounds a lot better than O(n) :-D
Best regards,
Theo
// Theo Schlossnagle
// CTO -- http
experience accepting incremental patches is a _bad_ idea unless you
have a VCS that has really makes it _easy_ to manage them. Sounds
like more work than worth on the postgres project as it is now.
Additionally, what problem is accepting incremental patches supposed
to solve?
// Theo
needed features, I rarely
see the attitude that they are _unwanted_. Instead I see the if it
is important to you, go build it attitude which is what I would
expect in an open source project.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc
user-space probes (I assume) is that
tracing C functions can be too granular and not conveniently expose
the right information to make tracing useful.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: Run
On Jun 19, 2006, at 6:41 PM, Robert Lor wrote:
Theo Schlossnagle wrote:
Heh. Syscall probes and FBT probes in Dtrace have zero
overhead. User-space probes do have overhead, but it is only a
few instructions (two I think). Besically, the probe points are
replaced by illegal
any probes at all
in the code - I guess a configure option --without-dtrace on by
default on those platforms would do it.
Absolutely. As they are all proposed as preprocessor macros, this
would be trivial to accomplish.
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus
-bit intel.
The bigger puzzle is why you could link against non-PIC code in shared
objects on 32-bit x86. (I know the answer, but it has no real merit).
If you want things dynamically loadable, they must be PIC.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus
the build system to properly handle the
preprocessing, it seems we have a problem with the ASM instructions.
Theo? Comments?
What platform is that? (OS rev, architecture and word size)? I tested
the changes I submitted on Solaris 10 amd64.
--
// Theo Schlossnagle
// Principal Engineer -- http
Kris Jurka wrote:
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c
can be compiled standalone with -DS_LOCK_TEST
To get the test to compile I had to link in tas.o as the attached
patch shows. Unfortunately this doesn't
Kris Jurka wrote:
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
What platform is that? (OS rev, architecture and word size)? I
tested the changes I submitted on Solaris 10 amd64.
$ uname -a
SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc
$ cc -V
cc: Sun WorkShop 6 update 2 C 5.3
Kris Jurka wrote:
On Fri, 28 Apr 2006, Theo Schlossnagle wrote:
Kris Jurka wrote:
Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.
on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.
This seems like a different
52 matches
Mail list logo
