ns. What
> queries in the system (aside from the one I was looking at) should be
> using them?
Generally, they're used when you could utilize multiple indexes for a
single query. But I think they first appeared in 8.1.
BTW, most folks got a 60-70% performance boost from 8.0 to
What version of PostgreSQL are you using? I'm somewhat surprised that
it's not doing any bitmap scans.
BTW, RAID5 is generally not a good idea for databases.
--
Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net
nding a command across the wire to a database server...
BTW, for performance-conscious folks, converting raw query calls into
functions/procedures could produce a good gain, *especially* in cases
where you're sending multiple commands to do something.
--
Decibel!, aka Jim C. Nasby, Database Archi
On Mon, Oct 23, 2006 at 10:01:04AM -0700, Aaron Stone wrote:
> On Mon, 2006-10-23 at 11:13 -0500, Jim C. Nasby wrote:
> > On Fri, Oct 20, 2006 at 12:05:43AM -0700, Aaron Stone wrote:
> > > Ok, I think we should change the query in db_getmailbox_count to be < 2
> > >
optimizer should be able to deal with just as well as
< 2.
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
ists about it. I'm
guessing the community won't be terribly interested in giving the
planner enough brains to know that IN(1,2) on an int column could be
converted to BETWEEN 1 AND 2, but you never know...
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your compu
On Mon, Oct 09, 2006 at 10:02:59AM +0200, Paul J Stevens wrote:
> Jim,
>
> I'm fixing this by changing all quoted longs and int to unquoted values.
Excellent. Why were they in there to begin with? Is that a MySQL-ism?
--
Jim C. Nasby, Database Architect[EMAIL PR
der versions it won't cast that automatically,
meaning an index on status is useless.
In any case, PostgreSQL handles IN the same as ( ... OR ... OR ... ).
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
W
and password, or an authentication
token. The procedures would then limit access to only that user's
information.
Of course, this doesn't mean that the system is hack-proof, but there's
a number of ways to greatly improve security without resorting to one
database per user.
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
mysql/postgres I think will have a noticeable improvement.
Absolutely. More important than the performance boost, it's the only
100% sure-fire way to protect yourself from SQL injection attacks.
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some
On Tue, Aug 15, 2006 at 11:47:20AM -0700, Aaron Stone wrote:
> On Tue, 2006-08-15 at 12:04 -0500, Jim C. Nasby wrote:
> > On Tue, Aug 15, 2006 at 09:39:06AM -0700, Aaron Stone wrote:
> [snip]
> > > One possible path to making this work is a PHP extension compiled
> >
u're back at porting weDBMail to the
> current schema...
What about using stored procs as an API into the database? I know that
raises some cross-database issues, but those aren't insurmountable (and
probably aren't much worse than dealing with the cross-database stuff in
C).
--
Jim
blah.
BTW, is there some trick to getting an account on the bug tracker? I
keep trying to register, but the emails never make it to me.
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you
hing else worth mentioning is that the default PostgreSQL settings
are very conservative; anyone who's concerned about performance should
increase shared_buffers to at least 10% of memory. In later releases,
people have seen large gains by going as high as 50%.
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
paul at nfg.nl
> > NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
> > The Netherlandshttp://www.nfg.nl
> >
>
> ___
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
Jim C. Nasby, Database Architect[EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
On Wed, Jun 21, 2006 at 04:41:19PM -0400, Geo Carncross wrote:
> On Wed, 2006-06-21 at 12:59 -0500, Jim C. Nasby wrote:
> > On Mon, Jun 19, 2006 at 08:02:02PM -0400, Geo Carncross wrote:
> > > > The point is, security and data intergrity *is* very important. But
> &
't patch dbmail.
>
> No, bind parameters don't eliminate sql injection attacks. It makes a
> certain kind quite difficult. The problem is escaping, and the
> developers already think they _are_ escaping in all the right places.
What kind of injection attacks do boun
r only a single use is worthwhile or not.
The cost is essentially the same, minus the added round-trips to the
database.
In any case, I fail to see how this is an issue: if you're using
dynamically generated code in performance critical areas of the server
you have bigger things to worry about
On Fri, Jun 16, 2006 at 12:37:47PM +0200, Paul J Stevens wrote:
>
>
> Jim C. Nasby wrote:
>
> > Is there some reason why bound parameters aren't being used? Aside from
> > the security aspect, they also provide a speed improvement.
>
> Prepared statements a
gfoundry.org/projects/veil/
But it'd be silly to go through all the trouble of setting up row-level
security if you're not going to protect against injection attacks in the
first place.
Is there some reason why bound parameters aren't being used? Aside from
the security aspect, they also provide a speed improvement.
--
Jim C. Nasby, Database Architect [EMAIL PROTECTED]
512.569.9461 (cell) http://jim.nasby.net
20 matches
Mail list logo