why that is better, or easier, than just invalidating the cached
plan if the cardinality changes.
---
Jim C. Nasby wrote:
On Wed, Dec 21, 2005 at 11:00:31PM -0500, Bruce Momjian wrote:
Track normal resource
the obvious cases of bad statistics or a DDL
change).
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
optimization to make if the function is
immutable and isn't otherwise referenced (ie: by WHERE or ORDER BY),
there's no reason I can think of to execute it as you read through the
rows. Might be able to do this with STABLE functions as well.
TODO?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
consumption.
This would at least make it easy for admins to identify prepared queries
that have a highly variable execution cost.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf
On Sat, Dec 17, 2005 at 01:07:10PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
Is cardinality the only thing we'd need to worry about? My idea was
actually to track the amount of work normally required by a stored query
plan, and if a query uses that plan but requires a very different
the dependent objects change or
when the cardinality of parameters changes dramatically
---
Jim C. Nasby wrote:
On Tue, Dec 13, 2005 at 04:49:10PM -0500, Neil Conway wrote:
On Tue, 2005-12-13 at 22:32 +0100, Joachim
if the updates are actually working.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
='AAA' AND id = '200501'
then I think the planner will know what selects it can simply ignore. If
that doesn't work, then add 'AAA'||id AS fullid to each of the selects
in the view and that should allow the function indexes to be used.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
aggregations and GROUP BY, but that's a problem for another day.
Might be worth adding a TODO for that and including links to the papers.
There's enough people that seem to drop in with PhD thesis and what-not
pulled from the TODO that someone could end up doing this work for us.
--
Jim C. Nasby
such as yourself.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 9
on AMD if testing there would help. I'll need a pointer to a
patch and test-case though...
Oh, I also have access to an old SGI...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
statement is
executed with a set of predicates that substantially changes the amount
of work required it should be remembered and considered for re-planning
the next time the query is executed with those predicates.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
on without a
dump/reload?
err, sorry. s/switch/upgrade/
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
!
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
(though at least you
wouldn't need to know the password to the postgres account).
I'd love to see something like SUDO ALTER USER ... SUDO REINDEX ... etc.
That would make it easy to do 'normal' work with a non-superuser
account.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
that throughput though, is latency. Because the latency
on memory is much closer to 0 (it's not truely 0 due to L1/L2 caching),
you can serve concurrent requests a lot faster.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512
On Mon, Dec 12, 2005 at 05:00:45PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I'd love to see something like SUDO ALTER USER ... SUDO REINDEX ... etc.
That would make it easy to do 'normal' work with a non-superuser
account.
You can already do most of this with SET
On Mon, Dec 12, 2005 at 05:27:33PM -0500, Andrew Dunstan wrote:
On Mon, Dec 12, 2005 at 05:00:45PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I'd love to see something like SUDO ALTER USER ... SUDO REINDEX ... etc.
That would make it easy to do 'normal' work
etc
Some SQL examples would be...
sudo CREATE USER ...
sudo UPDATE table SET ...
I have no idea what you're envisioning, but based on your description it
certainly doesn't sound like what I'm envisioning...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
and we did recently
upgrade to FreeBSD 6.0, but all the other branches are clean. Any ideas?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Dec 12, 2005 at 06:37:03PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Dec 12, 2005 at 05:43:47PM -0500, Rod Taylor wrote:
A sudo equivalent would be a version of psql that always connected to
the database using super-user and allowed command execution
gank it from playtypus's config.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
that it's probably worth adding a built-in
function, especially if it's faster to do the multiply (though
presumably a built-in function could outperform both the multiply and
the more common (4.5::float || ' seconds')::interval form.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED
.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 3: Have you checked
On Tue, Dec 13, 2005 at 02:03:13AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The error talks about SEMMNI and SEMMNS, but both look ok...
kern.ipc.semmns: 100
That's not enough to run two postmasters ...
Odd that it works for other branches...
That's a boot-time
On Thu, Dec 08, 2005 at 11:58:50AM +0200, Hannu Krosing wrote:
??hel kenal p??eval, N, 2005-12-08 kell 01:08, kirjutas Jim C. Nasby:
On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005
could do non-trigger-based
replication? (As well as non-trigger-based materialized views...)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
that. Because of how enable_seqscan works, I
couldn't.
BTW,
http://archives.postgresql.org/pgsql-performance/2005-04/msg00669.php is
where I first mentioned this, including the cost function that I think
is broken.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
this more performant.
Yes, I agree on all your points about better placement of new tuples,
all they would be useful indeed.
Sounds like a TODO, barring objections...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231
through to the mailing list cleanly
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
even with the added burden. If instead of
adding a fixed amount enable_seqscan=false multiplied by some amount
then this would probably be impossible to occur.
(And before someone asks, no, I don't remember which query was actually
faster...)
--
Jim C. Nasby, Sr. Engineering Consultant
an error? Just grab a lock that would prevent any new inserts
from occuring. Or at least make that an option.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569
sense to check only at the start of a transaction
and have an index build wait until all running transactions knew that an
index build was going to happen.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard
On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have
be some point in implementing a protocol-level equivalent of
RETURNING just to reduce the overhead on both sides, but I think we
ought to get the RETURNING functionality in place first and then worry
about that...
Along those lines, I don't see anything on the TODO list about this...
--
Jim C
On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
This seems like a useful feature to add, allowing for easy built-in
verticle partitioning. Are there issues with the patch as-is?
Other than the ones mentioned by the poster?
It seemed to me
: [pgsql-advocacy] joint booths at upcoming tradeshows
Thread-Index: AcX13EA7k+/T1h3MQS+/wKoOVRCB/QA8IzWg
From: Stephen Slezak [EMAIL PROTECTED]
To: Jim C. Nasby [EMAIL PROTECTED], Josh Berkus josh@agliodbs.com
Cc: Jim Nasby [EMAIL PROTECTED],
Bruce Momjian pgman@candle.pha.pa.us
to see what people over there
have to say.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
On Tue, Nov 29, 2005 at 01:35:09PM +0100, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
not have any unique indexes or row triggers. It should be possible to
take advantage
handy.
Is there still interest in this? I've got a dual Opteron running FBSD.
(What would be the profiler to use on FBSD?)
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf
on
pages that have space available? ISTM that's something users would want
to be able to over-ride. In fact, it seems like it shouldn't be a
default behavior...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard
recommended to always explicitely cast any constants in a
predicate.
Let me know if I'm on the wrong track with any of this, otherwise I'll
work on a set of patches.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
to have some way to specify in a command that
you want to use some kind of error-handling trigger. Though presumably
the underlying framework would be same, so it shouldn't be hard to
support both.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
textNOT NULL UNIQUE
);
I prefer having url_id as the PK because it's how you normally access
the table. But ISTM that there are cases where yo'd want to be able to
merge on two different sets of fields in one table, which is impossible
if we limit it to PK merges only.
--
Jim C. Nasby, Sr
On Mon, Nov 21, 2005 at 09:14:33PM +0100, Marcus Engene wrote:
Jim C. Nasby wrote:
It might be more useful to look at caching only planning and not
parsing. I'm not familiar with the output of the parsing stage, but
perhaps that could be hashed to use as a lookup into a cache of planned
would favor storing that info in a bitmap); likewise some
tables will have a small number of pages that are 'dirty', which would
favor storing a list of page numbers instead of a bitmap.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com
for admins, and it is impossible to do while the server is running.
Along those lines, is there anything else that would benefit from being
moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and
pg_twophase are candidates as well?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL
NOT NULL. ISTM it would be good to support that case as well, since you
might want to MERGE based on something other than the PK.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
actually be REPLACE/INSERT ON DUPLICATE UPDATE then
it's probably better to follow that lead.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
at all? Is the concern how long make check takes?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
a global project.
Plus it gives anyone in that area a chance to see if they can meet up
and buy you a beer/coke/name_your_poison.
Of course maybe that's reason not to publicize this info... ;P
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
On Thu, Nov 17, 2005 at 12:51:47AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoodt=2005-11-15%2023:56:22
I took a closer look at this, and noticed something interesting:
ccache gcc -no-cpp-precomp -O2 -fno-strict
useful to look at caching only planning and not
parsing. I'm not familiar with the output of the parsing stage, but
perhaps that could be hashed to use as a lookup into a cache of planned
queries. I suspect that would remove issues of different search_paths.
--
Jim C. Nasby, Sr. Engineering Consultant
finishing their I/O...
If that makes it into code, ISTM it would be good if it also threw a
NOTICE so that users could see if this was happening; kinda like the
notice about log files being recycled frequently.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf
instant then
you probably don't need an exact count in the first place and should be
happy enough with an estimate. He constantly cites Google ('Result 1-10
of about 38,923') as an example of this.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
also be used as the on-disk backing for
the FSM, or it could potentially replace the FSM.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
, but maybe there's some clever way around
that. If the proposal to track heap block-level metadata happens, that
might make this idea a lot more doable.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http
logic. You do not need a cast in the query, though,
only in the index's WHERE condition.
I'm working on a docs patch for this (attached, but un-tested); is
bigint the only datatype this applies to or are there others?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
pg_delete_all_users that dump called instead. For most of the dump this
isn't much of an issue, because it uses standard commands that we're
really careful about not breaking backwards compatability on.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
On Tue, Nov 15, 2005 at 10:27:06PM -0600, Jim C. Nasby wrote:
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl
On Wed, Nov 16, 2005 at 11:50:51AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?
Perhaps --- try otool -L (local equivalent of ldd) on them to find
out
'
and IF there is enough demand from users then the community might
consider a hack that allows running PostgreSQL from an admin account.
But as it stands right now, neither of those has been shown.
So as Stephan suggested, let's try looking at the root problem and see
if there's some way to fix that.
--
Jim C
things a lot more difficult
to do if you don't have admin on your account. Yes, there is runas, but
windows doesn't exactly foster people working from the command line. And
IIRC runas isn't nearly as nice to use as sudo.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
results in a tablescan (current definition of
STABLE). If there's performance benefits to be had on functions that are
both STABLE (as per the old definition) and don't modify any data (or
contain any volatile functions?) then that should be a new level of
stability.
--
Jim C. Nasby, Sr
On Mon, Nov 14, 2005 at 07:38:00PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Do we really need to prevent inserts from happening under a SELECT FOR
UPDATE? ISTM that's trying to apply serializable concurrency to SELECT
FOR UPDATE even if it's running in a read committed
was that the reason many windows users run with admin
rights is because windows doesn't provide a viable alternative (unlike
OS X).
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
On Tue, Nov 15, 2005 at 10:58:31AM -0600, Jim C. Nasby wrote:
BTW, my point was that the reason many windows users run with admin
rights is because windows doesn't provide a viable alternative (unlike
OS X).
Err, sorry, hit send too soon. My point about OS X isn't meant to start
a flame war
in configure that call for
libcrypto are SSL and KRB, neither of which are configured...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 6: explain analyze is your friend
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
for the limited cases we can,
and throw an error for cases we can not (or require table locking), and
then see what reports we get from users.
We should probably throw a notice or warning if we go to a table lock,
too.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
Tad hard to believe
On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
Tad hard to believe
, which could make
that --with-openssl bit cleaner...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
; it would be useful for development when you'd like to know
that some statement is grabbing a table lock. This is something that you
wouldn't normally notice in a dev environment, and it sounds like it'd
be easy to do a merge that has the unintended effect of grabbing a table
lock.
--
Jim C. Nasby, Sr
, but did not see anything
obvious.
Thank you,
Mike
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512
--
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
Jim C. Nasby, Sr
that mysql has a replace.
On another note, is there any reason we can't put an equivalent to
example 36-1 (http://lnk.nu/postgresql.org/617.html) into the backend?
Presumably it wouldn't be as fast as a more elegant solution, but OTOH
it'd probably be faster than plpgsql...
--
Jim C. Nasby, Sr
...). Is it possible? If not, can
it be added (add of a 'read-only' option).
Thanks in advance for your help.
Regards,
Eric LEGUILLIER
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--
Jim C. Nasby, Sr
=# insert into t values('1');
INSERT 633176 1
decibel=# select * from t;
t
---
1
1
(2 rows)
decibel=# update t set t='2';
# Blocks on session 2
Am I missing something here?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork
On Fri, Nov 04, 2005 at 08:46:27PM -0400, Marc G. Fournier wrote:
On Fri, 4 Nov 2005, Jim C. Nasby wrote:
For all the talk about couldn't it be part of regression, I haven't seen
anyone submit a patch that would test for it ... since I believe both you
and Tom have both stated
On Sat, Nov 05, 2005 at 11:48:56AM +0100, Martijn van Oosterhout wrote:
On Sat, Nov 05, 2005 at 10:47:30AM +0100, Jochem van Dieten wrote:
On 11/4/05, Jim C. Nasby wrote:
I would argue that in cases like this (and 'this' means just about any
DDL, for starters) that it would be better
On Tue, Nov 08, 2005 at 02:09:35PM -0700, Robert Creager wrote:
On Tue, 08 Nov 2005 14:09:58 -0600
Jim C. Nasby [EMAIL PROTECTED] wrote:
On Fri, Nov 04, 2005 at 08:46:27PM -0400, Marc G. Fournier wrote:
On Fri, 4 Nov 2005, Jim C. Nasby wrote:
For all the talk about couldn't it be part
and long enough to cover the subject
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
to mind is to allow explicit
specification of what's meant: '[1:1]{}' would be needed to represent
the one-null case. Ugly.
Instead of bending over backwards to try and support older cases, would
a compatability mode be possible? Seems that would solve a lot of
problems.
--
Jim C. Nasby, Sr
On Fri, Nov 04, 2005 at 08:06:39PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
My client (same one with the slru.c issue) has had 3 of these in the
past day...
(gdb) print *str
$39 = {data = 0x848030 2005-11-04 00:01:02 EST|2005-11-04 00:00:08
EST|216.187.113.78
the same effect. I realize that improving this
would probably involve a non-trivial amount of work, so maybe a good
compromise would be logging a warning anytime a relation is dropped due
to hitting max_fsm_relations.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
are on, but for performance reasons the memory checking stuff is
commented out.
The good news is there's been no slru.c asserts...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net
On Fri, Nov 04, 2005 at 02:45:41PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x003b8946fb20 in strlen () from /lib64/tls/libc.so.6
#1 0x003b894428dc in vfprintf () from /lib64
perfectly acceptable to have a char type that is a
fixed-width in terms of number of bytes, so long as we provide an
alternative. Heck, in my experience char is only used to store things
like hashes that are in ASCII anyway.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive
to regression, or maybe as a seperate
test case for the buildfarm?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
type. (BTW,
I'm not suggesting that we disallow un-disk storage of the type, only
discourage it unless someone really, really needs an absurd number of
digits).
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
can actually be done. Or at least make that an option.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end
On Fri, Nov 04, 2005 at 04:30:27PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Nov 03, 2005 at 10:32:03AM -0500, Tom Lane wrote:
I'd feel a lot happier about this if we could keep the dynamic range
up to, say, 10^512 so that it's still true that NUMERIC can
On Fri, Nov 04, 2005 at 04:35:10PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Could something like that be added to regression, or maybe as a seperate
test case for the buildfarm?
If you don't have a self-contained, reproducible test case, it's a bit
pointless
On Fri, Nov 04, 2005 at 04:34:35PM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Fri, Nov 04, 2005 at 02:45:41PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The backtrace:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0
and/or enabling assertions by default, IMHO.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast
to indicate that
going the other way around (one macro, two GUC's) wouldn't do any good.
BTW, I can do some testing of assert performance impact with dbt2 on a
Solaris box if anyone's interested in the data...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http
801 - 900 of 1317 matches
Mail list logo
