Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > select * from mytable where entry_time >= $1;
> >
> > The planner will take a seqscan when it sees this because it is worried
> > about the downside if a large fraction of the table is being selected.
I'll m
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > If the planner had the expected value as well as the variance of the cost
> > distribution then it might realize that in this case for instance that the
> > penalty for guessing wrong with an index scan is only going
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Ok, so something like this?
> 1) eval_const_expressions takes a list of parameter values and does
> Param to Const replacement if given parameters.
> 2) The main planner does not pass parameters to eval_const_expressions.
> 3) When the selectivity functi
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
This leads to my next problem (which was one of the original reasons I
went with node replacement): don't we get different performance between
a parameterized query and an equivalent unparameterized query in cases
such as this? :
SELEC
Oliver Jowett <[EMAIL PROTECTED]> writes:
> This leads to my next problem (which was one of the original reasons I
> went with node replacement): don't we get different performance between
> a parameterized query and an equivalent unparameterized query in cases
> such as this? :
>SELECT * F
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't like that at all. Do the planning using the given parameters,
but save the plan. Otherwise you have substantially pessimized the
behavior for the case where an unnamed statement is reused.
How often is the unnamed
there are currently no downloadable files ... I have to re-work archives
to add them back in, as there used to be such ...
On Fri, 21 May 2004, Dave Cramer wrote:
> You and me both, I'd like a copy of this too.
>
> Dave
> On Fri, 2004-05-21 at 13:58, Matthew T. O'Connor wrote:
> > Is there a do
Tom Lane wrote:
Au contraire --- a full-table index scan can be vastly slower than a
full-table seqscan. I think it's wishful thinking to assume that
picking an indexscan is the right thing when we don't know any better.
I wish we could get this basic truth across to users somehow - I have
lo
Greg Stark <[EMAIL PROTECTED]> writes:
> If the planner had the expected value as well as the variance of the cost
> distribution then it might realize that in this case for instance that the
> penalty for guessing wrong with an index scan is only going to be a small
> slowdown factor, perhaps 2-4x
Tom Lane <[EMAIL PROTECTED]> writes:
> select * from mytable where entry_time >= $1;
>
> The planner will take a seqscan when it sees this because it is worried
> about the downside if a large fraction of the table is being selected.
I wonder if it would make sense for the planner to be sm
Now that we have control of our own timezone code, one of the first
things I'd like to do with it is replace time_t with pg_time_t defined
as (signed) int8. This would allow us to handle timezone calculations
outside the 1904-2038 range, and in particular eliminate the bizarre
behaviors that curre
You and me both, I'd like a copy of this too.
Dave
On Fri, 2004-05-21 at 13:58, Matthew T. O'Connor wrote:
> Is there a downloadable version of the different postgresql mailling
> lists? Or even just individual files for different months? I would like
> to have a copy of possible, and lots of oth
Is there a downloadable version of the different postgresql mailling
lists? Or even just individual files for different months? I would like
to have a copy of possible, and lots of other OSS projects offer this, but
we don't, or at least I can't find it on the site. Did I miss it?
Thanks,
Matth
James William Pye <[EMAIL PROTECTED]> writes:
> On 05/20/04:20/4, Tom Lane wrote:
>> It's true that this setup doesn't allow non-SRFs to get at the econtext,
>> but I'm not sure that they need to.
> The only thing my goal has in common with getting at the econtext is
> the ability to register a ca
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm a bit concerned about driving such a change in behavior off nothing
>> more than whether the statement is named or not.
> Would it be better to bite the bullet and bump the protocol version,
> adding a new field to Parse to contro
On 05/20/04:20/4, Tom Lane wrote:
> It's true that this setup doesn't allow non-SRFs to get at the econtext,
> but I'm not sure that they need to.
The only thing my goal has in common with getting at the econtext is the ability
to register a callback that can clean up my fn_extra at a relatively
a
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > In the current build on the anon cvs server, if I try to \d a table
from
> > psql, the backend comes down. I played with the query a bit and
> > discovered any query using '~' operator in the where clause on any
table
> > (catalog or otherwise) ca
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> In the current build on the anon cvs server, if I try to \d a table from
> psql, the backend comes down. I played with the query a bit and
> discovered any query using '~' operator in the where clause on any table
> (catalog or otherwise) causes an im
> I have binary install from snapshot from the other night on WINDOWS
2000
> PRO and had same problem.
>
well, I'm the one compiling the snapshot :), so I trying to confirm that
I have not busted anything...when did you download the snapshot, though?
I switched to gcc 3.4 yesterday, was it earlier
I downloaded it this morning around 8:00 AM CENTRAL TIME. Thanks for the
builds by the way!
|-+-->
| | "Merlin Moncure" |
| | <[EMAIL PROTECTED]|
| | online.com>|
| |
In the current build on the anon cvs server, if I try to \d a table from
psql, the backend comes down. I played with the query a bit and
discovered any query using '~' operator in the where clause on any table
(catalog or otherwise) causes an immediate backend crash.
Can anybody confirm that this
I have binary install from snapshot from the other night on WINDOWS 2000
PRO and had same problem.
|-+-->
| | "Merlin Moncure" |
| | <[EMAIL PROTECTED]|
| | ne.com>|
|
I may have removed a few too many "#include " lines.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Thu, 2004-05-20 at 19:59, Gaetano Mendola wrote:
> Greg Copeland wrote:
>
> > On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
> >
> >>On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
> >>
> >>
> >>>fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> >>>to t
[EMAIL PROTECTED] wrote:
We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
license does take an amount of accounting.
I was using GPL as an example, as it was mentioned earlier in the
thread. My comments hold for *any* license, including (at least in the
UK; unfair contract
I get this:
gmake[4]: Entering directory
`/space/1/home/chriskl/pgsql/src/backend/access/gist'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../../src/include -c -o gist.o gist.c -MMD
In file included from ../../../../src/include/commands/vacuum.h:18,
Hi,
When you do this:
CREATE DATABASE test TEMPLATE master;
It doesn't copy any per-database GUC variables, created by the ALTER
DATABASE master SET var TO val; command.
Should it?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your
RHL 9.0
cvs HEAD, fresh update
make maintainer-clean
./configure --with-java --prefix=/home/grant/bin/pgsql/ \
--with-integer-datetimes --enable-debug --enable-cassert
make
yields:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -D_GNU_S
28 matches
Mail list logo
