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
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
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
v
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
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 unle
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
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
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
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
> > >
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 goi
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 t
"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 fr
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 --
"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. Even
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
"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 mor
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 c
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
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
> >
> > ht
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
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=mastodon&dt=2008-01-30%2020:00:00
Maybe I shouldn't have had those beers after work today, but that looks
like it's for examp
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=mastodon&dt=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 tsearc
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=mastodon&dt=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
Dave Page wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=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
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 happen
> -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 <[EMAI
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
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mastodon&dt=2008-01-30%2020:00:00
/D
---(end of broadcast)---
TIP 6: explain analyze is your friend
"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 prop
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 w
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 prob
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
"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'
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,
"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
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
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
f
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
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 wou
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 the
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 wh
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 guy
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 importan
> > 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
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
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
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 tra
48 matches
Mail list logo
