Greg Stark <[EMAIL PROTECTED]> writes:
>> Combining indexes via a bitmap intermediate step (which is not really
>> the same thing as bitmap indexes, IIUC) seems like a more robust
>> approach than relying on the index entries to be in ctid order.
> I would see that as the next step, But it seems t
>
> It seems reverse look up for "svr1.postgresql.org" fails.
> Due to this sendmail denies to receive mails relayed by
> svr1.postgresql.org (200.46.204.71).
>
> Jan 25 04:09:55 powergres sendmail[9622]:
> i0OJ9qY09622:
> ruleset=check_rcpt,
> arg1=<[EMAIL PROTECTED]>,
> relay=[2
> Hi,
>
> We have serious problems past 4 days in receiving mail lists from
> postgresql.org. Subscribers living in the jp domain are receiving via
> a relay host named powergres.sra.co.jp (this is an authorized relay
> host for jp domain, and this configuration has been approved by Marc).
>
> Af
Tom Lane <[EMAIL PROTECTED]> writes:
> I don't think so. You are thinking only of exact-equality queries ---
> as soon as the WHERE clause describes a range of index entries, the
> readout wouldn't be sorted by ctid anyway.
But then even bitmap indexes would fail in that way too, or at least ha
looking into it ... seems somewhere upstream changed their DNS config to
not pull our reverse information ... just had someone else point it out to
me as well :(
I've removed the jp relay temporarily, since it is failing, and hope to
have it resolved within the next 24hrs ...
Thanks ...
On Wed
Hi,
We have serious problems past 4 days in receiving mail lists from
postgresql.org. Subscribers living in the jp domain are receiving via
a relay host named powergres.sra.co.jp (this is an authorized relay
host for jp domain, and this configuration has been approved by Marc).
After checking the
Tom Lane wrote:
Okay ... Chris was kind enough to let me examine the WAL logs and
postmaster stderr log for his recent problem, and I believe that
I have now achieved a full understanding of what happened. The true
bug is indeed somewhere else than slru.c, and we would not have found
it if slru.c
POSTGRESQL: Summary of Changes since last release (7.4.1)
--
26 Jan 2004
This is a summary of most changes since code versions marked 7_4_1,
rather than a weekly news bulletin, a summary of desired future items,
or the definitive list of what
> Bruce Momjian wrote
> >Tom Lane wrote:
> > >"Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > If the TODO-list-with-dash isn't the correct place to have looked,
is
> > > there another list of committed changes for the next release?
> >
> > We tend to rely on the CVS commit logs as the definitive s
Andreas Pflug <[EMAIL PROTECTED]> writes:
> This would be the first time a SCSI disk lies about its write caching.
> There are plenty of low-cost (i.e. IDE) disks out there having a hidden
> write cache, but AFAIK a generic SCSI tool is usable to enable/disable
> the write cache.
A SCSI disk sh
On 01/27/04:04/2, Joshua D. Drake wrote:
> With the new preload option is there any benefit/drawback to using
> pl/Python versus
> pl/pgSQL? And no... I don't care that pl/Python is now considered
> untrusted.
Feature-wise I'm not exactly sure how pl/Python matches up against pl/pgSQL,
Greg Stark <[EMAIL PROTECTED]> writes:
> If you have two indexes (a,ctid) and (b,ctid) and do a query where a=1 and b=2
> then it would be particularly easy to combine the two efficiently.
> If specially marked btree indexes -- or even all btree indexes -- implicitly
> had ctid as a final sort or
[EMAIL PROTECTED] wrote:
Nothing special... And any option I could use would'nt change a thing:
the cache is on the disk itself... I did'nt look physicaly yet but
according to the docs there's no way to disable it lik I always did on
IBM...
I was forced to buy those disk (more expensive, not bett
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > How feasible would it be to have a btree index on ctid?
>
> Why would you want one? Direct access by ctid beats out an index lookup
> every time.
Of course. But as I mentioned, I have a cunning plan.
If you h
Greg Stark <[EMAIL PROTECTED]> writes:
> How feasible would it be to have a btree index on ctid?
Why would you want one? Direct access by ctid beats out an index lookup
every time. In any case, vacuum and friends would break such an index
entirely.
regards, tom lane
---
Rod Taylor <[EMAIL PROTECTED]> writes:
>> As a more direct response, there *are* reasons for people to put ORDER
>> BY in a subselect and expect it to be honored. The typical example
>> that's been discussed several times in the archives is that you want to
>> use an aggregate function that is sen
> As a more direct response, there *are* reasons for people to put ORDER
> BY in a subselect and expect it to be honored. The typical example
> that's been discussed several times in the archives is that you want to
> use an aggregate function that is sensitive to the ordering of its input
Not to
--On Tuesday, January 27, 2004 23:03:56 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 16:02:40 -0600
From: Larry Rosenman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list <[EMAIL PROTECTED]>
Subject: Re: Write cache
--On Tuesd
On Tue, 27 Jan 2004, Larry Rosenman wrote:
> Date: Tue, 27 Jan 2004 16:02:40 -0600
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: Write cache
>
>
>
> --On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrot
--On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:55:49 -0600
From: Larry Rosenman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list <[EMAIL PROTECTED]>
Subject: Re: Write cache
--On Tuesd
On Tue, 27 Jan 2004, Larry Rosenman wrote:
> Date: Tue, 27 Jan 2004 15:55:49 -0600
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: Write cache
>
>
>
> --On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrot
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
>> I'm saying the sort makes no sense. So why even bother executing it?
>>
>>> why did you write it?
>>
>> I believe the most common scenario would be that the subquery was
>> expanded from a view...
> And
--On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:45:20 -0600
From: Larry Rosenman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: pgsql-hackers list <[EMAIL PROTECTED]>
Subject: Re: Write cache
--On Tuesd
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> I'll read the rest of the mail more careful tomorrow moring, I just want
> to point out directly that for calls that doesn't use named arguments you
> get the exact same speed as before. Except for an extra if() to check if
> there are named arguments.
On Tue, 27 Jan 2004, Larry Rosenman wrote:
> Date: Tue, 27 Jan 2004 15:45:20 -0600
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: Write cache
>
>
>
> --On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrot
--On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote:
On Tue, 27 Jan 2004, Larry Rosenman wrote:
Date: Tue, 27 Jan 2004 15:38:30 -0600
From: Larry Rosenman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]>
Subject: Re: Write cache
IDE or SCSI?
SC
On Tue, 27 Jan 2004, Larry Rosenman wrote:
> Date: Tue, 27 Jan 2004 15:38:30 -0600
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: Write cache
>
> IDE or SCSI?
SCSI
>
> Why do you think the WC is screwing you?
>
Because afte
IDE or SCSI?
Why do you think the WC is screwing you?
Which driver(s)?
LER
--On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote:
Because I've lost a lot of data using postgresql (and I know for sure this
should'nt happen) I've gone a bit further reading documentations on my
di
"Ezra Epstein" <[EMAIL PROTECTED]> writes:
>> I do not think SET SESSION AUTH is a suitable replacement for logging
>> in. For one thing, it doesn't apply per-user GUC settings. For
> OK, what are GUC settings. Can SET SESSION AUTH be extended to do this as
> needed?
Not very easily; it's not
Because I've lost a lot of data using postgresql (and I know for sure this
should'nt happen) I've gone a bit further reading documentations on my
disks and...
I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write
cache of 8Mb, if someone could tell me hox to turn it off... Could'nt
Bruce Momjian wrote:
Woh, as far as I know, any application should run fine with -lpthread,
threaded or not. What OS are you on? This is the first I have heard of
this problem.
Perhaps we should try to figure out how other packages handle
multithreaded/singlethreaded libraries? I'm looking a
Dennis Haney kirjutas T, 27.01.2004 kell 21:08:
> Tom Lane wrote:
> > Dennis Haney <[EMAIL PROTECTED]> writes:
> >
> > > There is no constraint on the order of 'a', so why is pull_up_subqueries
> > > explicitly ignoring subqueries that contain an 'order by'?
> > >
> > Because there would
On Tue, 27 Jan 2004, Tom Lane wrote:
> speed hits in parsing them, especially not if the hit occurs whether
> one uses the named-parameters feature or not ...
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named argum
The Pl/Java project that I'm working on is progressing quite nicely. The
beta release that I just uploaded to GBorg at
http://gborg.postgresql.org/project/pljava/projdisplay.php has most of the
functionality that I have intended for the first stable release. If you are
interested, please take a loo
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Tue, 27 Jan 2004, Tom Lane wrote:
>> func_select_candidate() that involve comparing matches at "the same
>> argument position" will break down completely.
> I was planning to reorder the arguments before the matching according to
> the function pro
How feasible would it be to have a btree index on ctid? I'm thinking it ought
to work simply enough for the normal case of insert/delet/update, but I'm not
completely certain how vacuum, vacuum full, and cluster would interact.
You may think this would be utterly useless, but I have a cunning pla
On Jan 27, 2004, at 1:16 PM, Steve Atkins wrote:
A hint, though, might be that it's a multiprocess application with a
single master process that controls dozens of child processes. When the
master shuts down it asks all the children to shut down, and then it
deadlocks in the SIGCHILD handler.
It's
On Tue, 27 Jan 2004, Peter Eisentraut wrote:
> just a question of what syntax to use. Personally, I would be OK with
> "=>".
That's also what I'm leaning towards now. As Greg suggested, just making
=> a special case as a function parameter. And if one want's to call a
function with an expressio
On Tue, 27 Jan 2004, Tom Lane wrote:
> In particular, how will you avoid individually trawling through every
> function with a matching name to try to match up the arguments?
I don't think you can avoid that. But it's just done once to find the oid
of the real function, so if it's used multiple t
Tom Lane wrote:
> Are you sure you're reading that correctly?
Not anymore... :-/ Sorry for the noise. I had remembered that in some
context and were
interchangeable, but apparently I got it all mixed up.
---(end of broadcast)---
TIP 7: don't
On Tue, Jan 27, 2004 at 02:07:44PM -0500, Bruce Momjian wrote:
> Steve Atkins wrote:
> > > My guess is that creating applications against the non-thread libpq and
> > > then replacing it with a threaded libpq is your problem.
> >
> > Yes. It seems to make no difference whether the application is
Hello,
With the new preload option is there any benefit/drawback to using
pl/Python versus
pl/pgSQL? And no... I don't care that pl/Python is now considered
untrusted.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, progra
Interesting it works now, and the good news is it is *WAY* faster, this
might be able to speed up marc's doc search by orders of magnitude
this is searching 100536 rows
select * from url where fn_strrev(url) like fn_strrev('%beta12.html');
1.57ms
explain select * from url where url like '%beta
Tom Lane wrote:
Dennis Haney <[EMAIL PROTECTED]> writes:
There is no constraint on the order of 'a', so why is pull_up_subqueries
explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation.
Then why spend tim
Steve Atkins wrote:
> > My guess is that creating applications against the non-thread libpq and
> > then replacing it with a threaded libpq is your problem.
>
> Yes. It seems to make no difference whether the application is rebuilt
> or not. It's pulling libpthread into a non-thread-aware applica
Bruno Wolff III wrote:
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney <[EMAIL PROTECTED]> wrote:
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or dis
On Fri, Jan 23, 2004 at 10:03:30PM -0500, Bruce Momjian wrote:
> Steve Atkins wrote:
> > When I rebuilt libpq to use threads, I started seeing a bunch of weird
> > failures in many of the older applications. The change in libpq meant
> > that libpthread was being dynamically linked into the non-thr
Dave Cramer <[EMAIL PROTECTED]> writes:
> I'm using 7.4.1, the db was initdb --locale='C'
> and no I don't get them on plain indexes
Oh? If it's 7.4 then you can confirm the locale selection with
"show lc_collate" and "show lc_ctype" (I think the first of these
is what the LIKE optimization
"Ezra Epstein" <[EMAIL PROTECTED]> writes:
>>> I'd like to extend SET SESSION AUTHORIZATION to support a form
>>> which takes a password.
>>
> Uh, a password? What purpose would that serve?
> For exactly the opposite usage: allowing a non-privileged user to take on a
> different authorization IF
I'm using 7.4.1, the db was initdb --locale='C'
and no I don't get them on plain indexes
Dave
On Tue, 2004-01-27 at 13:28, Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > Tried, all the suggestions
>
> Mph. It works for me... what PG version are you using exactly,
> and are y
Dave Cramer <[EMAIL PROTECTED]> writes:
> Tried, all the suggestions
Mph. It works for me... what PG version are you using exactly,
and are you certain you've selected C locale? (Do you get LIKE
optimization on plain indexes?)
regards, tom lane
-
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> SQL99 part 2 clause 16.1 contains this note:
> NOTE 327 - The characteristics of a transaction begun by a
> are as specified in these General
> Rules regardless of the characteristics specified by any
> preceding . That is, even if one
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Dennis Bjorklund wrote:
>> Thinking more about it, I'm not sure if it really is an important
>> addition at all. I've got a number of requests for the feature. so
>> there are people that want it, that much I know.
> I like it very much, and I think m
Tried, all the suggestions
--dc--
davec=# explain analyze select * from url where fn_strrev(url) like
fn_strrev('%beta12.html');
QUERY PLAN
---
Dennis Haney <[EMAIL PROTECTED]> writes:
> There is no constraint on the order of 'a', so why is pull_up_subqueries
> explicitly ignoring subqueries that contain an 'order by'?
Because there would be no place to apply the sort operation. If you are
saying you don't want the sort to occur, why di
Dave Cramer <[EMAIL PROTECTED]> writes:
> davec=# explain analyze select * from url where fn_strrev(url) like
> '%beta12.html';
Don't you need the % at the right end to have an indexable plan?
I suspect that both of your tries so far are actually semantically
wrong, and that what you intend is
se
On Tue, Jan 27, 2004 at 12:41:41PM -0500, Dave Cramer wrote:
> davec=# explain analyze select * from url where fn_strrev(url) like
> '%beta12.html';
Reverse the constant too:
davec=# explain analyze select * from url where fn_strrev(url) like
fn_strrev('%beta12.html');
You won't get an indexsca
On Tue, 27 Jan 2004, Dave Cramer wrote:
> same answer
>
> davec=# show enable_seqscan;
> enable_seqscan
>
> off
> (1 row)
>
> davec=# explain analyze select * from url where fn_strrev(url) like
> '%beta12.html';
That's still an unanchored like clause, besides I think that woul
same answer
davec=# show enable_seqscan;
enable_seqscan
off
(1 row)
davec=# explain analyze select * from url where fn_strrev(url) like
'%beta12.html';
QUERY PLAN
On Tue, Jan 27, 2004 at 17:27:25 +0100,
Dennis Haney <[EMAIL PROTECTED]> wrote:
>
> Is it just me, or is there any way a sort could be relevant in a
> subquery? (except on queries containing volatile functions)
Yes. It is important when a limit or distinct on clause is used in a
subquery.
---
Dave Cramer <[EMAIL PROTECTED]> writes:
> create index r_url_idx on url( fn_strrev(url));
> explain select * from url where url like fn_strrev('%beta12.html');
>QUERY PLAN
> -
> Seq Scan on url (cost=0.00..13281.70 r
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Tom Lane writes
>> In particular, the optimization paths that involve unique-ifying the
>> subselect output and then using it as the outer side of a join would
>> definitely not work for these sorts of things.
> I'm not sure if I've understood you corre
SQL99 part 2 clause 16.1 contains this note:
NOTE 327 - The characteristics of a transaction begun by a
are as specified in these General
Rules regardless of the characteristics specified by any
preceding . That is, even if one
or more characteristics are omitted by the , the
On Tue, 27 Jan 2004, Tom Lane wrote:
> Date: Tue, 27 Jan 2004 12:02:04 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] Most urgent
>
> [EMAIL PROTECTED] writes:
> > My server just had a bad crash...
> > At reb
Dennis Bjorklund wrote:
> Thinking more about it, I'm not sure if it really is an important
> addition at all. I've got a number of requests for the feature. so
> there are people that want it, that much I know.
I like it very much, and I think mostly everyone else does, too. It's
just a questio
[EMAIL PROTECTED] writes:
> My server just had a bad crash...
> At reboot time, the pg_xlog filesystem didn't mount...
So mount it...
If you're trying to say that the xlog is irretrievably hosed, then see
pg_resetxlog, and be prepared to spend some time checking to see if
anything got corrupted.
I've been looking in the sql200x draft and there are no function calls
with named arguments.
Thinking more about it, I'm not sure if it really is an important addition
at all. I've got a number of requests for the feature. so there are people
that want it, that much I know.
I don't think it's v
Hi
Is it just me, or is there any way a sort could be relevant in a
subquery? (except on queries containing volatile functions)
select a.* from test1 a, (select id from test1 order by num) as b where
a.id = b.id;
There is no constraint on the order of 'a', so why is pull_up_subqueries
explici
My mistake then. Better to check than let
a logical hole in… Thanks for letting me know, Simon
-Original
Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Haney
Sent: Tuesday, January 27, 2004
14:33
To: [EMAIL PROTECTED]
Cc: 'Tom Lane';
[EMAIL PRO
On Fri, 2004-01-23 at 00:21, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan wrote:
> >> AFAIK the only target build environment for Windows right now is MinGW/gcc
> >>
> >> If anyone knows how to get the M$ compilers to work nicely with our build
> >> system that mi
Simon Riggs wrote:
Tom Lane writes
In the second place, what the code is doing is dependent on an
understanding
of the semantics of IN; I'm not sure it's applicable to, say,
WHERE outervar > ANY (SELECT innervar FROM ...)
and it's definitely not applicable to
WHERE outervar > ALL (SE
I'm curious what the result of a reverse index does on a table with url
like data, so I did the following
create function fn_strrev(text) returns text as 'return reverse($_[0])'
language 'plperl' with (iscachable);
create index r_url_idx on url( fn_strrev(url));
vacuum analyze;
explain select
I tried to build plperl on 7.4.1,
On my system
perl -MConfig -e 'print $Config{ccdlflags}'
returns
-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE
however the build ends up using
-rpath,$prefix/lib
Dave
--
Dave Cramer
519 939 0336
ICQ # 1467551
> Tom Lane writes
>
> In the second place, what the code is doing is dependent on an
> understanding
> of the semantics of IN; I'm not sure it's applicable to, say,
> WHERE outervar > ANY (SELECT innervar FROM ...)
> and it's definitely not applicable to
> WHERE outervar > ALL (SELECT
> Tom Lane writes
>
> In the second place, what the code is doing is dependent on an
> understanding
> of the semantics of IN; I'm not sure it's applicable to, say,
> WHERE outervar > ANY (SELECT innervar FROM ...)
> and it's definitely not applicable to
> WHERE outervar > ALL (SELECT
Scott Lamb wrote:
On Jan 25, 2004, at 3:07 AM, Brian Moore wrote:
1
2
How would you filter for a column in XSLT based on column name with
this schema? It's certainly not trivial. I have similar code, and I
included the column name as an attribute in each column eleme
On Jan 25, 2004, at 3:07 AM, Brian Moore wrote:
it's been said that converting a PGresult into xml is "trivial" and
that's why it hasn't been done in the codebase as of yet. i have seen
much code that writes xml, and many mistakes are made. most often
improper escaping, or writing to a schema/DTD t
My server just had a bad crash...
At reboot time, the pg_xlog filesystem didn't mount...
The I have those errors at startup...
is there anything can do to recover?
Jan 27 13:24:11 server postgres[3469]: [3-1] LOG: checkpoint record is at 7/B7668
Jan 27 13:24:11 server postgres[3469]: [4-1] LOG:
The attached patch changes the existing behaviour of length(char(n)).
Currently, this is what happens:
template1=# select length('blah'::char(10));
length
10
(1 row)
With this patch:
template1=# select length('blah'::char(10));
length
4
(1 row)
This behaviour was
79 matches
Mail list logo
