Hi,
The fundamental question though is should we allow primary, unique
CONSTRAINTS which use the index mechanism just as an implementation to
be
created using the INCLUDING INDEXES mechanism.
Yeah, this bizarreness was foreseen and agreed to back when we set up
LIKE INCLUDING
On Wed, 2007-11-28 at 09:38 -0800, Trevor Talbot wrote:
PostgreSQL's problem is that it (and AFAICT POSIX) conflates encoding
with locale, when the two are entirely separate concepts.
In what way does PostgreSQL conflate encoding with locale?
-Neil
---(end of
Recently there was a post on -performance about a particular case where
Postgres doesn't make very good use of the I/O system. This is when you try to
fetch many records spread throughout a table in random order.
http://archives.postgresql.org/pgsql-performance/2007-12/msg5.php
Currently
On 12/2/07, Gregory Stark [EMAIL PROTECTED] wrote:
The two interfaces I'm aware of for this are posix_fadvise() and libaio. I've
run tests with a synthetic benchmark which generates a large file then reads a
random selection of blocks from within it using either synchronous reads like
we do
Louis-David Mitterrand wrote:
Wow, this above email took three days to reach to list.
Received: from maia-2.hub.org (maia-2.hub.org [200.46.204.187])
by zenon.apartia.fr (Postfix) with ESMTP id
2B95E59C5B43C
for [EMAIL PROTECTED]; Sat, 1
Douglas McNaught [EMAIL PROTECTED] writes:
On 12/2/07, Gregory Stark [EMAIL PROTECTED] wrote:
The two interfaces I'm aware of for this are posix_fadvise() and libaio. I've
run tests with a synthetic benchmark which generates a large file then reads
a
random selection of blocks from within
Gregory Stark [EMAIL PROTECTED] writes:
Recently there was a post on -performance about a particular case where
Postgres doesn't make very good use of the I/O system. This is when you try to
fetch many records spread throughout a table in random order.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Recently there was a post on -performance about a particular case where
Postgres doesn't make very good use of the I/O system. This is when you try
to
fetch many records spread throughout a
On Dec 2, 2007 7:40 AM, Dragan Zubac [EMAIL PROTECTED] wrote:
Hello
I have a stored procedure which does the billing stuff
in our system,it works ok,but if I put in
production,where there is some 5-10 billing events per
second,the whole database slows down. It won't even
drop some test
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Recently there was a post on -performance about a particular case where
Postgres doesn't make very good use of the I/O system. This is when you try
to
fetch many records spread throughout a table in random order.
Hello
Please find in attachment stored procedure
(proc_uni.txt),as well as description of tables
involved in calculations.
The idea for procedure is to find longest prefix match
for destination number,try to find it in table
'billing' for particular users,find the price,and
insert message into
Hello
Here's the stored procedure itself,as well as the
related tables involved in it's calculations.
The idea for procedure is to find longest prefix match
for destination number,try to find it in table
'billing' for particular users,find the price,and
insert message into history and inqueue
So while poking around contrib/spi and trying to put together an SGML
doc file for it, I realized that the preprocessor/ subdirectory seems
entirely useless. What it does is generate CREATE TRIGGER commands
for use with contrib/spi/refint.c, given SQL input that includes FOREIGN
KEY clauses.
[EMAIL PROTECTED] (Tom Lane) wrote:
Log Message:
---
Improve the manual's discussion of partitioning. Recommend using a
trigger instead of a rule to redirect insertions, use NEW.* notation
where appropriate, some other updates and adjustments. David Fetter
and Tom Lane
I have a
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I have a fix (1) and two comments (2 and 3) in the documentation.
1. IF (logdate) should be IF (NEW.logdate) in the trigger function.
INSERT fails without NEW. before logdate.
How embarrassing ... I tested the other parts of the example, but not
Josh Berkus wrote:
Arul Shaji
Sydney, Australia.
Rgds,
Arul Shaji
16 matches
Mail list logo
