On Fri, 2 Jun 2006, Rodrigo Hjort wrote:
Oleg,
Actually I got PG 8.1.4 compiled from source on a Debian GNU/Linux
2.6.16-k7-2.
My locale is pt_BR, but I configured TSearch2 to use rules from the
'simple'.
Then I just followed the instructions from the link. The fact is that it
only works at
Aha,
I got the same problem on 8.2dev.
Oleg
On Fri, 2 Jun 2006, Rodrigo Hjort wrote:
Oleg,
Actually I got PG 8.1.4 compiled from source on a Debian GNU/Linux
2.6.16-k7-2.
My locale is pt_BR, but I configured TSearch2 to use rules from the
'simple'.
Then I just followed the
Think about version API compatibility.
Suppose you have a working database on server A which uses module foo
version 1.
Some time passes, you buy another server B and install postgres on it.
Meanwhile the module foo has evolved into version 2 which is cooler, but
has some minor
I was also vaguely pondering whether all the DDL commands could be
generalized
to receive or send COPY formatted data for repeated execution. It would
be
neat to be able to prepare an UPDATE with placeholders and stream data
in COPY
format as parameters to the UPDATE to execute it
PFC [EMAIL PROTECTED] writes:
I was also vaguely pondering whether all the DDL commands could be
generalized to receive or send COPY formatted data for repeated execution.
It would be neat to be able to prepare an UPDATE with placeholders and
stream data in COPY format as parameters to
Greg Stark [EMAIL PROTECTED] writes:
PFC [EMAIL PROTECTED] writes:
MySQL already does this for INSERT :
INSERT INTO x (a,b) VALUES (1,2), (3,4), (5,6)...;
Does MySQL really let you stream that? Trying to do syntax like that in
Postgres wouldn't work because the parser would try to build up a
MySQL already does this for INSERT :
INSERT INTO x (a,b) VALUES (1,2), (3,4), (5,6)...;
Does MySQL really let you stream that? Trying to do syntax like that in
Postgres wouldn't work because the parser would try to build up a parse
tree
for the whole statement before
Hello,
Sometimes people complain that UPDATE is slow in postgres. UPDATE...
- generates dead tuples which must be vacuumed.
- needs to hit all indexes even if only one column was modified.
From what I know UPDATE creates a new copy of the old row with the
Mark Woodward wrote:
Mark Woodward wrote:
...
This runs completely in the background and can serve as a running
backup.
And you are sure it would be much faster then a server local running
psql just dumping the result of a query?
No I can't be sure of that at all, but The COPY
PFC [EMAIL PROTECTED] writes:
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
moving a lot of overhead into SELECT in order to make UPDATE cheaper,
and on top of that the restriction to same-page will limit the
usefulness quite a lot (unless we
On Jun 2, 2006, at 10:27 AM, Andrew Dunstan wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What's happening here is that cvs actually creates the directory
and then later prunes it when it finds it is empty.
I find that explanation pretty
On Jun 2, 2006, at 5:24 PM, Todd A. Cook wrote:
Josh Berkus wrote:
Greg, Tom,
But for most users analyze doesn't really have to run as often as
vacuum. One sequential scan per night doesn't seem like that big
a deal
to me.
Clearly you don't have any 0.5 TB databases.
Perhaps something
Tom Lane [EMAIL PROTECTED] writes:
Supporting VALUES only in INSERT would be relatively trivial BTW,
but the spec actually thinks it should be allowed as a table spec
in FROM ...
How does that syntax work?
INSERT INTO x (a,b) from select x,y,z from t from select x2,y2,z2 from t
? doesn't
Jim Nasby wrote:
yes, it's a file/directory it doesn't know about.
At one stage I suppressed these checks, but I found that too many
times we saw errors due to unclean repos. So now buildfarm insists
on having a clean repo.
I suppose I could provide a switch to turn it off ... in
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Supporting VALUES only in INSERT would be relatively trivial BTW,
but the spec actually thinks it should be allowed as a table spec
in FROM ...
How does that syntax work?
If you look at SQL92, INSERT ... VALUES is
Ühel kenal päeval, L, 2006-06-03 kell 10:43, kirjutas Jim Nasby:
Might also be worth adding analyze delay settings, ala
vacuum_cost_delay.
Actually we should have delay settings for all potential
(almost-)full-scan service ops, - VACUUM, ANALYSE, CREATE INDEX, ADD
CONSTRAINT, maybe more - so
Tom Lane [EMAIL PROTECTED] writes:
The interesting point here is that a subquery is defined as a
parenthesized query expression, which means that you ought to be able to
use a parenthesized VALUES list anyplace you could use a parenthesized
SELECT. So FROM lists, IN clauses, = ANY and
Ühel kenal päeval, R, 2006-06-02 kell 16:23, kirjutas Greg Stark:
And a 5% sample is a pretty big. In fact my tests earlier showed the i/o from
5% block sampling took just as long as reading all the blocks. Even if we
figure out what's causing that (IMHO surprising) result and improve matters
pgbench appears to already support arbitrary SQL queries with the -f
switch, so why couldn't we just make it a little smarter and have people
enable SQL query logging for a day or two, then pass the log off to
pgbench:
pgbench -f log file
Seems to me like that wouldn't be too difficult to do,
Hannu Krosing [EMAIL PROTECTED] writes:
Disks can read at full rotation speed, so skipping (not reading) some
blocks will not make reading the remaining blocks from the same track
faster. And if there are more than 20 8k pages per track, you still have
a very high probablility you need to
Greg Stark wrote:
It would have been awfully nice to do be able to do
SELECT ... FROM (VALUES (a,b,c),(d,e,f),(g,h,i))
The trouble with supporting it for any case other than INSERT is that
you have to work out what the column datatypes of the construct ought
to be. This is the same as
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, May 31, 2006 at 01:08:28PM -0700, Steve Atkins wrote:
On May 31, 2006, at 12:58 PM, Dave Page wrote:
On 31/5/06 19:13, Andreas Pflug [EMAIL PROTECTED] wrote:
I wonder if we'd be able to ship gzip with the windows
Andreas Pflug wrote:
Tom Lane wrote:
After re-reading what I just wrote to Andreas about how compression of
COPY data would be better done outside the backend than inside, it
struck me that we are missing a feature that's fairly common in Unix
programs. Perhaps COPY ought to have the
Original Message
From: Tom Lane [EMAIL PROTECTED]
kudu HEAD: one-time failure 6/1/06 in statement_timeout test, never seen
before. Is it possible system was under enough load that the 1-second
timeout fired before control reached the exception block?
The load here was
On Saturday 03 June 2006 17:27, Tom Lane wrote:
PFC [EMAIL PROTECTED] writes:
[snip - complicated update logic proprosal]
What do you think ?
Sounds enormously complicated and of very doubtful net win --- you're
[snip - ... bad idea reasoning] :)
What if every backend while
25 matches
Mail list logo
