On Mon, Sep 19, 2005 at 10:53:44AM -0400, Tom Lane wrote:
> Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> > So no need to hold the new dot releases? :)
>
> I still object to releasing them until we find out what's going on
> on gerbil. That machine was building 8.0 fine until the patch, and it's
>
Andrew Dunstan wrote:
>
> While preparing for a presentation, I noticed some mildly ugly effects
> with log_line_prefix during session startup if log_connections is turned on.
>
> Example (log_line_prefix = '%t [EMAIL PROTECTED] %r %p %c:%l'):
>
> 2005-09-19 19:16:39 EDT [EMAIL PROTECTED] 6541
Added to TODO:
* Allow DISTINCT to use hashing like GROUP BY
---
Greg Stark wrote:
>
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2005-19-09 at 16:27 +0200, Hans-J?rgen Sch?nig wrote:
> > > I was wond
Magnus Hagander wrote:
> > It occurs to me that there is no longer any great need to
> > have a separate hackers list for win32 development. Perhaps
> > we should close it down now and keep all development on -hackers?
>
> I also think this is a good idea. The number of "win32 only issues of
> -
Jonah H. Harris wrote:
Mark,
If you don't mind contributing the changes, we'd be glad to take a look
at them. Thanks.
-Jonah
Ok, we will post it back soon. We have tested it on two different 64-bit
architectures (Sparc and AMD) and are now testing on pentium before posting up
to the li
While preparing for a presentation, I noticed some mildly ugly effects
with log_line_prefix during session startup if log_connections is turned on.
Example (log_line_prefix = '%t [EMAIL PROTECTED] %r %p %c:%l'):
2005-09-19 19:16:39 EDT [EMAIL PROTECTED] 6541 432f46d7.198d:1 LOG:
connection
I have removed this TODO item:
* Research use of sched_yield() for spinlock acquisition failure
---
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Marko Kreen writes:
> > (I speculate that it's set u
Tom Lane <[EMAIL PROTECTED]> writes:
> I do think hash aggregation is a plausible alternative implementation of
> plain DISTINCT, but I don't see the case for using it for DISTINCT ON.
It could be done without presorting the input though not with a simple
first()-like function. It would have be a
On Mon, Sep 19, 2005 at 03:59:35PM -0400, Tom Lane wrote:
> Patrick Welche <[EMAIL PROTECTED]> writes:
> > I seem to have an unhappy postgresql:
>
> Let's see a test case, not a stack trace.
I haven't set up the minimalist test case yet, but the 2 tables involved
are incredibly simple. stats.id i
Patrick Welche <[EMAIL PROTECTED]> writes:
> I seem to have an unhappy postgresql:
Let's see a test case, not a stack trace.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore yo
Greg Stark <[EMAIL PROTECTED]> writes:
> DISTINCT is really just special a case of GROUP BY. Even DISTINCT ON is just
> GROUP BY with a kind of "first()" aggregate function. What would be really
> neat would be to teach GROUP BY about first() and last() and how it can skip
> over some index entries
On Mon, Sep 19, 2005 at 06:12:54PM +0100, Patrick Welche wrote:
> #15 0x081a4c2f in exec_simple_query (
> query_string=0x834501c "select timesliced, count(stats_id) from trans
> left j
I just truncated one line early.. the query was:
# explain select timesliced, count(stats_id) from trans le
On Mon, 2005-19-09 at 10:57 -0400, Tom Lane wrote:
> Any change like that would require another initdb. If we were going to
> force another initdb, my vote would be to revert these functions to
> where they were in beta1.
What purpose would that serve? About the only thing purpose I can see is
to
-Original Message-
From: "Marc G. Fournier"<[EMAIL PROTECTED]>
Sent: 19/09/05 16:56:23
To: "Tom Lane"<[EMAIL PROTECTED]>
Cc: "Marc G. Fournier"<[EMAIL PROTECTED]>, "Magnus Hagander"<[EMAIL
PROTECTED]>, "Andreas Pflug"<[EMAIL PROTECTED]>, "Dave
Page",
"pgsql-hackers@postgresql.org"
Subjec
Oliver Jowett wrote:
> Bruce Momjian wrote:
>
> > Well, from the application writer perspective, you are right it doesn't
> > make sense,
>
> This is exactly what the end user is going to say.
>
> > but this is only because jdbc is using prepare internally.
>
> Isn't this mostly irrelevant to
Simon Riggs wrote:
> On Fri, 2005-09-16 at 20:48 -0400, Bruce Momjian wrote:
> > We can go three ways. We can add a boolean GUC to control printing of
> > the query during a timeout, but that seems like overkill. We can add a
> > new level for log_min_error_statement that is just above error, but
I seem to have an unhappy postgresql:
(gdb) bt
#0 0xbd99871b in kill () from /usr/lib/libc.so.12
#1 0xbda217e7 in abort () from /usr/lib/libc.so.12
#2 0x0820c1fa in ExceptionalCondition (
conditionName=0x8298920 "!(batchno > hashtable->curbatch)",
errorType=0x823919f "FailedAssertion",
On Mon, Sep 19, 2005 at 12:21:00PM -0400, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > The thing is that these opclasses you're describing are closely related.
> > > It
> > > ought to be possible to use a single index to produce results
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > The thing is that these opclasses you're describing are closely related. It
> > ought to be possible to use a single index to produce results in any of the
> > four orders you describe.
>
> Wrong --- only two of the
On Mon, 19 Sep 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Is there a reason the old/new can't be aliaseed to each other, instead of
the old just being removed?
Any change like that would require another initdb. If we were going to
force another initdb, my vote would
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-19-09 at 16:27 +0200, Hans-Jürgen Schönig wrote:
> > I was wondering whether it is possible to teach the planner to handle
> > DISTINCT in a more efficient way:
> [...]
> > Isn't it possible to perform the same operation using a
> > HashAggr
Greg Stark <[EMAIL PROTECTED]> writes:
> The thing is that these opclasses you're describing are closely related. It
> ought to be possible to use a single index to produce results in any of the
> four orders you describe.
Wrong --- only two of them. You can't magically swap nulls from one end
of
Martijn van Oosterhout writes:
> On Sun, Sep 18, 2005 at 11:23:01PM -0400, Tom Lane wrote:
>
> > class families" to relate opclasses for different datatypes. Basically
> > I'd like to solve most of these issues by constructing a new layer atop
> > opclasses, not by deciding that an opclass doe
> > Is there a reason the old/new can't be aliaseed to each
> other, instead
> > of the old just being removed?
>
> Any change like that would require another initdb. If we
> were going to force another initdb, my vote would be to
> revert these functions to where they were in beta1. It was
It would also be very handy to be able to tell how many transactions (or
inserts/updates/deletes) have occured since the last vacuum. Presumably
autovacuum needs to know this already, but is it exposed?
On Thu, Sep 15, 2005 at 07:46:26AM -0400, Jim Buttafuoco wrote:
> while you are at it, can you
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> I was wondering whether it is possible to teach the planner to handle
> DISTINCT in a more efficient way:
Probably (although the interactions with ORDER BY might be tricky).
No one has touched that part of the planner in a ver
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I think beta 2 is a good time to start fixing up the translations again.
One thing I had wanted to do before issuing the call for translations
was to make a pass over the recent GiST changes, looking at
elog-vs-ereport decisions and message wording.
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Is there a reason the old/new can't be aliaseed to each other, instead of
> the old just being removed?
Any change like that would require another initdb. If we were going to
force another initdb, my vote would be to revert these functions to
wher
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
> So no need to hold the new dot releases? :)
I still object to releasing them until we find out what's going on
on gerbil. That machine was building 8.0 fine until the patch, and it's
failing consistently since then. To assume this is not our problem
wo
On Mon, 2005-19-09 at 16:27 +0200, Hans-Jürgen Schönig wrote:
> I was wondering whether it is possible to teach the planner to handle
> DISTINCT in a more efficient way:
[...]
> Isn't it possible to perform the same operation using a
> HashAggregate?
One problem is that DISTINCT ON is defined to
I was wondering whether it is possible to teach the planner to handle
DISTINCT in a more efficient way:
em=# explain select distinct lastname from import.testtest;
QUERY PLAN
Uniq
Hi,
On Fri, 16 Sep 2005, Michael Fuhr wrote:
On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
test REL8_0_STABLE with gerbil's configure options wh
Mark,
If you don't mind contributing the changes, we'd be glad to take a look at them. Thanks.
-JonahOn 9/18/05, Mark Dilger <[EMAIL PROTECTED]> wrote:
My company has written a 64-bit large object API, extending the postgresqlserver to be able to read/write/seek/tell/open/close objects larger th
On E, 2005-09-19 at 11:24 +0200, Martijn van Oosterhout wrote:
> On Mon, Sep 19, 2005 at 11:13:05AM +0300, Hannu Krosing wrote:
> > > (1) IS NULL is not an indexable operation, so no, not without
> > > significant overhaul of the index AM API.
> >
> > But we do store NULLs in indexes, so why is it
On Mon, Sep 19, 2005 at 11:13:05AM +0300, Hannu Krosing wrote:
> > (1) IS NULL is not an indexable operation, so no, not without
> > significant overhaul of the index AM API.
>
> But we do store NULLs in indexes, so why is it not indexable?
>
> This is either an interface bug (not making use of s
> > Also, the change to pg_cancel_backend breaks backwards
> compatibility
> > with 8.0, which is a whole lot worse than breaking it with
> 8.1-beta1.
>
> Yeah, I thought about that (and Bruce and I already discussed
> it offlist before I committed the changes). The function was
> newly added
> >>> Also, the change to pg_cancel_backend breaks backwards
> compatibility
> >>> with 8.0, which is a whole lot worse than breaking it with
> >> 8.1-beta1.
> >>
> >> Unfortunately, core doesn't see this as backward
> compatibility break,
> >> instead it's regarded as adjustment of a new funct
Sorry for offtopic, since the pgsql-general ML does not seem to work I post
here.
I checked the documentation, and still do not get it. I can use SPI_copytuple
to return a modified version of a tuple, but how do I modify a column of
type HeapTuple.
In my case, I just want to modify a INT32 col
On P, 2005-09-18 at 23:34 -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> That would be an extremely bad idea, because it would immediately remove
> >> index scans as one way to meet an ORDER BY.
>
> > Well couldn't the index scan be
39 matches
Mail list logo
