Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I suggest
cannot execute \%s\ on \%s\ because ...
Hmm, why not just
cannot execute %s \%s\ because ...
?
Hmm, yeah, that seems fine too. Thinking more about it, from the POV of
the translator
On Tue, 2008-01-29 at 22:12 -0800, Dann Corbit wrote:
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~300100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~~PRODLETT~C.html
http://www.nvidia.com/object/cuda_learn.html
http://www.nvidia.com/object/cuda_get.html
I assume you mean
The plural seems better to me; there's no such thing as a solitary
synchronized scan, no? The whole point of the feature is to affect
the behavior of multiple scans.
+1. The plural is important IMHO.
ok, good.
As I stated earlier, I don't really like this argument (we already
broke
On Sun, Jan 27, 2008 at 10:04:38PM +0100, Gevik Babakhani wrote:
Do you have the dumpbin command available in the path?
//Magnus
:) yes. This is why I do not understand why the command does not run
correctly!
Strange indeed. I recognise this problem from earlier, but I thought it
On Wed, Jan 30, 2008 at 10:56:47AM +0100, Zeugswetter Andreas ADI SD wrote:
The plural seems better to me; there's no such thing as a solitary
synchronized scan, no? The whole point of the feature is to affect
the behavior of multiple scans.
+1. The plural is important IMHO.
Zeugswetter Andreas ADI SD escribió:
The plural seems better to me; there's no such thing as a solitary
synchronized scan, no? The whole point of the feature is to affect
the behavior of multiple scans.
+1. The plural is important IMHO.
ok, good.
Hmm, if you guys are going to
On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Rather than having a boolean GUC, we should have a number and make the
parameter synchronised_scan_threshold.
This would open up a can of worms I'd prefer not to touch, having to do
with whether the
On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Notes: As the syntax shows, these would be statement-level triggers
(only). Requesting row level triggers will cause an error. [As Chris
Browne explained, if people really want, they can use these
All,
Added to TODO:
* Add anonymous transactions
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php
IMHO, autonomous transactions should be part of a package with a
spec-compliant CREATE PROCEDURE statement.That is, the difference
between PROCEDURES and FUNCTIONS
Josh Berkus escribió:
All,
Added to TODO:
* Add anonymous transactions
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php
IMHO, autonomous transactions should be part of a package with a
spec-compliant CREATE PROCEDURE statement.
IMHO we should try to get both things
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, if you guys are going to add another GUC variable, please hurry
because we have to translate the description text.
Yeah, I'm going to put it in today --- just the on/off switch.
Any discussions of exposing threshold parameters will have to wait
for
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have problems because not
Dann Corbit [EMAIL PROTECTED] writes:
http://www.nvidia.com/object/cuda_get.html
The license terms here seem to be sufficient reason why not.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list
2008/1/30 Dann Corbit [EMAIL PROTECTED]:
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~300100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~~PRODLETT~C.html
http://www.nvidia.com/object/cuda_learn.html
http://www.nvidia.com/object/cuda_get.html
Someone at CMU has tried this,
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
One more question. It would be possible that a session that turned off
the synchronized_seqscans still be a pack leader for other later
sessions.
Do/should we consider that ?
Seems like a reasonable thing to consider ... for 8.4. I'm not
On Wed, 2008-01-30 at 13:07 -0500, Tom Lane wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
One more question. It would be possible that a session that turned off
the synchronized_seqscans still be a pack leader for other later
sessions.
Do/should we consider that ?
Seems
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have
On Wed, 2008-01-30 at 18:42 +, Heikki Linnakangas wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a
Christopher Browne [EMAIL PROTECTED] writes:
This was based on GPUSort:
http://gamma.cs.unc.edu/GPUSORT/
I looked briefly at GPUSort a while back. I couldn't see how to shoehorn into
POstgres the assumption that you're always sorting floating point numbers. You
would have to add some property
Simon Riggs wrote:
On Wed, 2008-01-30 at 18:42 +, Heikki Linnakangas wrote:
It's even worse than that. Elsewhere in this thread Simon mentioned a
partitioned table, where each partition on its own is smaller than the
threshold, but you're seq scanning several partitions and the total size
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Christopher Browne
Sent: Wednesday, January 30, 2008 9:56 AM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Will PostgreSQL get ported to CUDA?
2008/1/30 Dann Corbit [EMAIL
Stephen Denne wrote:
I said...
On Windows XP, using Process Explorer with the lower pane showing
Handles, not all postgres.exe processes are including an Event
type with a description of what the process is doing.
I've had difficulty reproducing this, but I now suspect that it is
only
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
/D
---(end of broadcast)---
TIP 6: explain analyze is your friend
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing tsearch2, which hasn't been touched for
over a month!
Any chance there's something dodgy
Dave Page wrote:
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing
On Jan 30, 2008 9:21 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
I won't have access to my MSVC box until tomorrow, but unless beaten to
it I can dig into it a bit more. I don't see anything obvious int he
latest patches thoughy (but again, that could be the beer :-P).
Any chance you could
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example failing tsearch2, which hasn't
Dave Page wrote:
On Jan 30, 2008 9:13 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodondt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for example
Magnus Hagander [EMAIL PROTECTED] writes:
On Sun, Jan 27, 2008 at 09:32:54PM -0500, Stephen Frost wrote:
While I'm complaining: that's got to be one of the least useful error
messages I've ever seen, and it's for a case that's surely going to be
fairly common in practice. Can't we persuade
On Wed, 2008-01-30 at 17:55 +, Christopher Browne wrote:
2008/1/30 Dann Corbit [EMAIL PROTECTED]:
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~300100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~~PRODLETT~C.html
http://www.nvidia.com/object/cuda_learn.html
On Mon, Jan 28, 2008 at 11:14:05PM +, Christopher Browne wrote:
On Dec 6, 2007 6:28 PM, Decibel! [EMAIL PROTECTED] wrote:
FWIW, I've never seen anything but a performance increase or no change
when going from 10 to 100. In most cases there's a noticeable
improvement since it's common to
Decibel! [EMAIL PROTECTED] writes:
I think that before doing any of that you'd be much better off
investigating how much performance penalty there is for maxing out
default_statistict_target. If, as I suspect, it's essentially 0 on
modern hardware, then I don't think it's worth any more
Andrew Dunstan [EMAIL PROTECTED] writes:
None of the CVS changes in the relevant period seems to have any
relation to the errors, so I suspect a local problem.
skylark and baiji are now red too, so I guess that theory is dead in the
water. Something in today's changes broke the MSVC build,
On Jan 31, 2008 12:08 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Decibel! [EMAIL PROTECTED] writes:
I think that before doing any of that you'd be much better off
investigating how much performance penalty there is for maxing out
default_statistict_target. If, as I suspect, it's
Guillaume Smet [EMAIL PROTECTED] writes:
On Jan 31, 2008 12:08 AM, Gregory Stark [EMAIL PROTECTED] wrote:
That's not my experience. Even just raising it to 100 multiplies the number
of
rows ANALYZE has to read by 10. And the arrays for every column become ten
times larger. Eventually they
I wrote:
I diffed yesterday's and today's make logs from skylark, and found
nothing interesting except this:
***
*** 605,611
Generating POSTGRES.DEF from directory Release\postgres^M
! Generated 5208 symbols^M
Linking...^M
--- 605,611
Dave Page [EMAIL PROTECTED] writes:
I can't remember the last time I logged into that box so if it's
something in the buildenv, it's either caused by a Windows update,
Re-reading the thread ... could that last point be significant? Are
all four of these boxen set to auto-accept updates from
Tom Lane wrote:
* Has the buildfarm script changed recently in a way that might change
the execution PATH and thereby suck in a different version of dumpbin?
(Or even a different version of Perl?)
No. In at least the case of red_bat nothing has changed for months.
* Is it conceivable
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we set it, we're going to have
Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'm still not very happy with any of the options here.
BAS is great if you didn't want to trash the cache, but its also
annoying to people that really did want to load a large table into
cache. However we
Bruce Momjian [EMAIL PROTECTED] writes:
Another question --- why don't we just turn off synchronized_seqscans
when we do COPY TO? That would fix pg_dump and be transparent.
Enforcing this from the server side seems a pretty bad idea. Note that
there were squawks about having pg_dump behave
On Jan 30, 2008 5:58 PM, Decibel! [EMAIL PROTECTED] wrote:
On Mon, Jan 28, 2008 at 11:14:05PM +, Christopher Browne wrote:
On Dec 6, 2007 6:28 PM, Decibel! [EMAIL PROTECTED] wrote:
FWIW, I've never seen anything but a performance increase or no change
when going from 10 to 100. In
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Another question --- why don't we just turn off synchronized_seqscans
when we do COPY TO? That would fix pg_dump and be transparent.
Enforcing this from the server side seems a pretty bad idea. Note that
there were squawks about
Tom Lane wrote:
Neither of these sound very plausible, but it seems the next step for
investigation is to look closely at what's happening in gendef.pl.
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, I have found the problem. It is this line, which I am amazed hasn't
bitten us before:
next unless /^\d/;
The first field in the dumpbin output looks like a 3 digit hex number.
Argh, so it was crossing a power-of-2 boundary that got us.
Bruce Momjian [EMAIL PROTECTED] writes:
OK, but keep in mind if we use synchronized_seqscans in pg_dump we will
have to recognize that GUC forever.
No, because it's being used on the query side, not in the emitted dump.
We have *never* promised that pg_dump version N could dump from server
On Mon, Jan 28, 2008 at 09:09:13PM -0300, Alvaro Herrera wrote:
Decibel! wrote:
On Fri, Jan 25, 2008 at 11:40:19AM +, Simon Riggs wrote:
(for 8.4 ...)
I'd like to introduce triggers that fire when we issue a truncate:
Rather than focusing exclusively on TRUNCATE, how about
On Wed, Jan 30, 2008 at 09:13:37PM -0500, Christopher Browne wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
Tom points out:
eqjoinsel(), for one, is O(N^2) in the number of MCV values kept.
It seems to me that there
48 matches
Mail list logo
