> I was told that DB2 has per-table (or rather per-tablespace) knowledge
> of disk speeds, so keeping separate random and seqsqan costs for each
> table and index could be a good way here (to force use of a particular
> index make its use cheap)
>
I was wondering something even easier, keeping 1
On Thu, 2002-04-25 at 08:42, Luis Alberto Amigo Navarro wrote:
> >
> > (2) Use programmatic hints which allow coders specify which indexes are
> used
> > during a query. (ala Oracle)
> >
> As I said before it would be useful a way to improve(not force) using
> indexes on particular queries, i.e. l
>
> (2) Use programmatic hints which allow coders specify which indexes are
used
> during a query. (ala Oracle)
>
As I said before it would be useful a way to improve(not force) using
indexes on particular queries, i.e. lowering the cost of using this index on
this query.
Regards
---
On Thu, 2002-04-25 at 00:46, mlw wrote:
> We have had several threads about index usage, specifically when PostgreSQL has
> the choice of using one or not.
>
> There seems to be a few points of view:
>
> (1) The planner and statistics need to improve, so that erroneously using an
> index (or not
On Wed, 24 Apr 2002, Michael Loftis wrote:
> A Block-sized read will not be rboken up. But if you're reading ina
> size bigger than the underlying systems block sizes then it can get
> broken up.
In which operating systems, and under what circumstances?
I'll agree that some OSs may not coales
A Block-sized read will not be rboken up. But if you're reading ina
size bigger than the underlying systems block sizes then it can get
broken up.
So yes a sequential read will get broken up. A single read request for
a block may or may not get broken up. If you're freading with set block
Neil Conway wrote:
> Hi all,
>
> Why does the password_encryption GUC variable default to false?
>
> AFAICT there shouldn't be any issues with client compatibility -- in
> fact, I'd be inclined to rip out all support for storing cleartext
> passwords...
It is false so passwords can be handled b
Tom Lane wrote:
>Curt Sampson <[EMAIL PROTECTED]> writes:
>
>>Grabbing bigger chunks is always optimal, AFICT, if they're not
>>*too* big and you use the data. A single 64K read takes very little
>>longer than a single 8K read.
>>
>
>Proof?
>
I contend this statement.
It's optimal to a point.
Hi all,
Why does the password_encryption GUC variable default to false?
AFAICT there shouldn't be any issues with client compatibility -- in
fact, I'd be inclined to rip out all support for storing cleartext
passwords...
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]>
PGP Key ID: DB3C29FC
-
On Wed, 24 Apr 2002, mlw wrote:
> I am not arguing about whether or not they do it, I am saying it is
> not always possible. I/O requests do not remain in queue waiting for
> reordering indefinitely.
It doesn't matter. When they go out to the disk they go out in
order. On every Unix-based OS I k
Well, this is a very interesting email. Let me comment on some points.
---
Curt Sampson wrote:
> On Wed, 24 Apr 2002, Bruce Momjian wrote:
>
> > > 1. Not all systems do readahead.
> >
> > If they don't, that isn't ou
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Grabbing bigger chunks is always optimal, AFICT, if they're not
> > *too* big and you use the data. A single 64K read takes very little
> > longer than a single 8K read.
>
> Proof?
Long time ago I tested with the 32k block size and got 1.5-2x speed
Curt Sampson <[EMAIL PROTECTED]> writes:
> Grabbing bigger chunks is always optimal, AFICT, if they're not
> *too* big and you use the data. A single 64K read takes very little
> longer than a single 8K read.
Proof?
regards, tom lane
---(end of br
On Wed, 24 Apr 2002, Bruce Momjian wrote:
> > 1. Not all systems do readahead.
>
> If they don't, that isn't our problem. We expect it to be there, and if
> it isn't, the vendor/kernel is at fault.
It is your problem when another database kicks Postgres' ass
performance-wise.
And at that p
Bruce Momjian wrote:
>
> > > >
> > > > What are you expecting for psql e.g. the following
> > > > wrong(?) example ?
> > > >
> > > > [The curren schema is schema1]
> > > > begin;
> > > > create schema foo;
> > > > set search_path = foo;
> > > > create table t1
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > >
> > > What are you expecting for psql e.g. the following
> > > wrong(?) example ?
> > >
> > > [The curren schema is schema1]
> > > begin;
> > > create schema foo;
> > > set search_path = f
Mario Weilguni wrote:
> Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
> > OK, I have applied the following patch to fix these warnings. However,
> > I need Mario to confirm these are the right changes. Thanks.
>
> I've checked it and works fine, but the memcpy() prototype says it sho
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> >
> > What are you expecting for psql e.g. the following
> > wrong(?) example ?
> >
> > [The curren schema is schema1]
> > begin;
> > create schema foo;
> > set search_path = foo;
> > create table t1 (); [err
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > Hiroshi, we need a psql solution too. People are feeding query files
> > into psql all the time and we should have an appropriate behavior for
> > them.
>
> What are you expecting for psql e.g. the following
> wrong(?)
Michael Loftis wrote:
>
> Bruce Momjian wrote:
>
> >Hiroshi, we need a psql solution too. People are feeding query files
> >into psql all the time and we should have an appropriate behavior for
> >them.
> >
> >I now understand your point that from a ODBC perspective, you may not
> >want SETs rol
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> Hiroshi, we need a psql solution too. People are feeding query files
> into psql all the time and we should have an appropriate behavior for
> them.
What are you expecting for psql e.g. the following
wrong(?) example ?
[The curren schema i
Jan Wieck wrote:
>
> Hiroshi Inoue wrote:
> > > Sure should it! You gave an example for the need to roll
> > > back, because
> > > otherwise you would end up with an invalid
> > > search path "foo".
> >
> > What's wrong with it ? The insert command after *rollback*
> > would
Michael Loftis wrote:
>
> Hiroshi Inoue wrote:
>
> >Where's the restriction that all objects in a schema
> >must be created in an transaction ? Each user has his
> >reason and would need various kind of command call sequence.
> >What I've mainly insisted is what to do with errors is
> >users' resp
Bruce Momjian wrote:
>Hiroshi, we need a psql solution too. People are feeding query files
>into psql all the time and we should have an appropriate behavior for
>them.
>
>I now understand your point that from a ODBC perspective, you may not
>want SETs rolled back and you would rather ODBC han
It seems we can create a forein key using REFERENCES privilege but
cannot drop the table if its owner is not same as the referenced
table. Is this a feature or bug?
-- create a table as user foo
\c - foo
create table t1(i int primary key);
-- grant reference privilege to user bar
grant references
Hiroshi Inoue wrote:
> > Sure should it! You gave an example for the need to roll
> > back, because
> > otherwise you would end up with an invalid
> > search path "foo".
>
> What's wrong with it ? The insert command after *rollback*
> would fail. It seems the right thing to
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> >
> > Must I understand this from your previous posting
> > (2 says roll back only after transaction aborts,)
> > or original posting ? What I understood was 2 only
> > says that SET fails between a failure and the
> > subsequenct ROLLBACK call.
>
>
Hiroshi Inoue wrote:
>Michael Loftis wrote:
>
>>Hiroshi Inoue wrote:
>>
>>>What's wrong with it ? The insert command after *rollback*
>>>would fail. It seems the right thing to me. Otherwise
>>>the insert command would try to append the data of the
>>>table t1 to itself. The insert command is fo
Bruce Momjian wrote:
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > Bruce Momjian wrote:
> > > > >
> > > > > > > >
> > > > > > > > I voted not only ? but also 2 and 3.
> > > > > > > > And haven't I asked twice or so if it's a vote ?
> > > > > > >
> > > >
Hiroshi Inoue wrote:
> Michael Loftis wrote:
> >
> > Hiroshi Inoue wrote:
> >
> > >What's wrong with it ? The insert command after *rollback*
> > >would fail. It seems the right thing to me. Otherwise
> > >the insert command would try to append the data of the
> > >table t1 to itself. The insert
Curt Sampson wrote:
> On Wed, 24 Apr 2002, Bruce Momjian wrote:
>
> > We expect the file system to do re-aheads during a sequential scan.
> > This will not happen if someone else is also reading buffers from that
> > table in another place.
>
> Right. The essential difficulties are, as I see it:
Michael Loftis wrote:
>
> Hiroshi Inoue wrote:
>
> >What's wrong with it ? The insert command after *rollback*
> >would fail. It seems the right thing to me. Otherwise
> >the insert command would try to append the data of the
> >table t1 to itself. The insert command is for copying
> >schema1.t1
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > > > >
> > > > > > > I voted not only ? but also 2 and 3.
> > > > > > > And haven't I asked twice or so if it's a vote ?
> > > > > >
> > > > > > Yes, it is a vote, and now that we se
On Wed, 24 Apr 2002, Bruce Momjian wrote:
> We expect the file system to do re-aheads during a sequential scan.
> This will not happen if someone else is also reading buffers from that
> table in another place.
Right. The essential difficulties are, as I see it:
1. Not all systems do readah
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > > > >
> > > > > > I voted not only ? but also 2 and 3.
> > > > > > And haven't I asked twice or so if it's a vote ?
> > > > >
> > > > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > > > dec
* mlw ([EMAIL PROTECTED]) [020424 18:51]:
>
> (2) Use programmatic hints which allow coders specify which indexes are used
> during a query. (ala Oracle)
We would certainly use this if it were available. Hopefully not to
shoot ourselves in the foot, but for the rather common case of having
a sm
Hiroshi Inoue wrote:
>What's wrong with it ? The insert command after *rollback*
>would fail. It seems the right thing to me. Otherwise
>the insert command would try to append the data of the
>table t1 to itself. The insert command is for copying
>schema1.t1 to foo.t1 in case the previous create
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > > > >
> > > > > I voted not only ? but also 2 and 3.
> > > > > And haven't I asked twice or so if it's a vote ?
> > > >
> > > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > > decide what to do.
> > > >
> > > > Hiroshi,
Bruce Momjian wrote:
>
> > > >
> > > > I voted not only ? but also 2 and 3.
> > > > And haven't I asked twice or so if it's a vote ?
> > >
> > > Yes, it is a vote, and now that we see how everyone feels, we can
> > > decide what to do.
> > >
> > > Hiroshi, you can't vote for 2, 3, and ?.
> >
> > W
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > Bruce Momjian wrote:
> > > >
> > > > OK, the votes are in:
> > > >
> > > > #1
> > > > Lamar Owen
> > > > Jan Wieck
> > > > Tom Lane
> > > > Bruce Momjian
> > > > Joe Conw
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > OK, the votes are in:
> > >
> > > #1
> > > Lamar Owen
> > > Jan Wieck
> > > Tom Lane
> > > Bruce Momjian
> > > Joe Conway
> > > Curt Sampson
> > > Mich
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > OK, the votes are in:
> >
> > #1
> > Lamar Owen
> > Jan Wieck
> > Tom Lane
> > Bruce Momjian
> > Joe Conway
> > Curt Sampson
> > Michael Loftis
> > Vince Vielhaber
> >
Bruce Momjian wrote:
>
> OK, the votes are in:
>
> #1
> Lamar Owen
> Jan Wieck
> Tom Lane
> Bruce Momjian
> Joe Conway
> Curt Sampson
> Michael Loftis
> Vince Vielhaber
> Sander Steffann
>
> #2
> Brad
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Honetsly I don't understand what kind of example you
> expect. How about the following ?
> [The curren schema is schema1]
> begin;
> create schema foo;
> set search_path = foo;
> create table t1 ();
> .
>[error occ
Jan Wieck wrote:
>
> Hiroshi Inoue wrote:
> > Tom Lane wrote:
> > >
> >
> > > Right offhand, I am not seeing anything here for which there's a
> > > compelling case not to roll it back on error.
> > >
> > > In fact, I have yet to hear *any* plausible example of a variable
> > > that we would reall
Hiroshi Inoue wrote:
> Tom Lane wrote:
> >
>
> > Right offhand, I am not seeing anything here for which there's a
> > compelling case not to roll it back on error.
> >
> > In fact, I have yet to hear *any* plausible example of a variable
> > that we would really seriously want not to roll back on
OK, the votes are in:
#1
Lamar Owen
Jan Wieck
Tom Lane
Bruce Momjian
Joe Conway
Curt Sampson
Michael Loftis
Vince Vielhaber
Sander Steffann
#2
Bradley McLean
Tom Lane wrote:
>
> Right offhand, I am not seeing anything here for which there's a
> compelling case not to roll it back on error.
>
> In fact, I have yet to hear *any* plausible example of a variable
> that we would really seriously want not to roll back on error.
Honetsly I don't understan
Bruce Momjian wrote:
>
> OK, would people please vote on how to handle SET in an aborted
> transaction? This vote will allow us to resolve the issue and move
> forward if needed.
>
> In the case of:
>
> SET x=1;
> BEGIN;
> SET x=2;
> query_that_aborts_transaction
We have had several threads about index usage, specifically when PostgreSQL has
the choice of using one or not.
There seems to be a few points of view:
(1) The planner and statistics need to improve, so that erroneously using an
index (or not) happens less frequently or not at all.
(2) Use prog
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> select compilation_options();
> This assumes that compilation options only matter in the server and that
> only SQL users would be interested in them. In fact, compilation options
> affect client and utility programs as well, and
Thanks Dave.
I will create the project at gborg.postgresql.org on
Friday :)
> You might want to look at
> http://gborg.postgresql.org.
>
> Regards, Dave.
___
Yahoo! Empregos
O trabalho dos seus sonhos
Igor Kovalenko writes:
> It depends. QNX4 may be used with GCC, in which case it does have long long.
> I am not sure if that combination will play along with Postgres, but it
> should not be assumed impossible.
The point is, it should not be assumed possible.
--
Peter Eisentraut [EMAIL PROT
Tom Lane writes:
> You write You get
>
> char(N) pg_catalog.bpchar
> pg_catalog.char pg_catalog.char (not bpchar)
> real pg_catalog.float4
> myschema.real myschema.real (not float4)
>
On Wed, 24 Apr 2002, Michael Loftis wrote:
> Vote number 1 -- ROLL BACK
I agree.. Number 1 - ROLL BACK
>
> Bruce Momjian wrote:
>
> >OK, would people please vote on how to handle SET in an aborted
> >transaction? This vote will allow us to resolve the issue and move
> >forward if needed.
> >
Tom Lane writes:
> This could usefully be combined with the nearby thread about recording
> configuration options (started by Thomas). I'd be inclined to make it
> a low-footprint affair where you do something like
>
> select compilation_options();
>
> and you get back a long textual list
It depends. QNX4 may be used with GCC, in which case it does have long long.
I am not sure if that combination will play along with Postgres, but it
should not be assumed impossible.
- Original Message -
From: "Peter Eisentraut" <[EMAIL PROTECTED]>
To: "Thomas Lockhart" <[EMAIL PROTECTED]
Thomas Lockhart writes:
> Right. The two areas which come to mind are integer availability and the
> timezone support (as you might know we support *three* different time
> zone models). At the moment, none of the developers know the features
> supported on the platforms we claim to support. Whic
Vote number 1 -- ROLL BACK
Bruce Momjian wrote:
>OK, would people please vote on how to handle SET in an aborted
>transaction? This vote will allow us to resolve the issue and move
>forward if needed.
>
>In the case of:
>
> SET x=1;
> BEGIN;
> SET x=2;
> query_that_abort
Am Mittwoch, 24. April 2002 16:03 schrieb Bruce Momjian:
> OK, I have applied the following patch to fix these warnings. However,
> I need Mario to confirm these are the right changes. Thanks.
I've checked it and works fine, but the memcpy() prototype says it should be
void pointers. Will this
Here's today's tidbit for those who like to argue about nitty little
details of behavior ...
Presently, the parser (in particular gram.y) has quite a few special
transformations for certain type and function names. For example,
You write You get
char(N)
I was thinking in something independent from the executor, simply a variable
that recommends or not the use of a particular index, it could be obtained
from user, and so it could be improved(a factor lower than 1) on planner.
How about something like this?
- Original Message -
From: "Bruc
Steffen Nielsen <[EMAIL PROTECTED]> writes:
> Any Ideas why? Are there restriction on the size of text a stored procedure
> can return?
One gig ...
It's hard to guess what you're doing wrong when you haven't shown us
your code.
regards, tom lane
---
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Let me give you some examples. We might someday have nested
> transactions, or transactions which can be resumed from the point of
> failure. We *might* want to be able to affect recovery behaviors, and we
> *might* want to do so with something like
>
[Please CC any replies, I'm subscribed nomail]
As promised I've given it a bit of polish and it's actually almost useful.
You can have a look at it http://svana.org/kleptog/pgsql/pgfsck.html
Just unpack the files into a directory. It's just a perl script with two
modules so no compiling necessar
Philip Warner <[EMAIL PROTECTED]> writes:
> At 16:46 15/04/02 +0200, Mario Weilguni wrote:
>> And how about getting database internals via SQL-functions - e.g. getting
>> BLCSIZE, LOBBLCSIZE?
> ISTM that there would be some merit in making a selection of compile-time
> options available via SQL
I wanted to correct the patch this evening after work, and will check your changes.
Thanks!
-Ursprüngliche Nachricht-
Von: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 24. April 2002 16:03
An: Peter Eisentraut
Cc: Mario Weilguni; [EMAIL PROTECTED]
Betreff: Re: [HACKERS] I
> OK, would people please vote on how to handle SET in an aborted
> transaction?
> at the end, should 'x' equal:
> 1 - All SETs are rolled back in aborted transaction
> 2 - SETs are ignored after transaction abort
> 3 - All SETs are honored in aborted transaction
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, 64 looked like the appropriate value too. Actually, I was
> surprised to see as much of a slowdown as we did.
I was too. pgbench runs the same backend(s) throughout the test,
so it shouldn't be paying anything meaningful in disk I/O for the
large
Curt Sampson wrote:
> At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
>
> >This is an interesting point, that an index scan may fit in the cache
> >while a sequential scan may not.
>
> If so, I would expect that the number of pages read is significantly
> smaller than it was with a sequential sc
OK, I have applied the following patch to fix these warnings. However,
I need Mario to confirm these are the right changes. Thanks.
---
Peter Eisentraut wrote:
> This patch does not compile correctly:
>
> pg_backup_archi
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > ...Based on that data, I'd vote against making any changes to NAMEDATALEN.
>
> It looked to me like the cost for going to NAMEDATALEN = 64 would be
> reasonable. Based on these numbers I'd have a problem with 128 or more.
>
> But as
Hiroshi Inoue wrote:
> > I'd be willing to consider making the behavior variable-specific
> > if anyone can identify particular variables that need to behave
> > differently. But overall I think it's better that the behavior
> > be consistent --- so you'll need a good argument to convince me
> >
> If you want to collect information about what features are portable you
> can check other software packages, product manuals, ports trees, etc.
> Most issues are documented someplace.
Oh goodness. Thanks for offering me a new hobby ;)
> Btw., yes, 8 byte integers are missing on some platforms.
Hi!
I seem to have trouble returning large strings of text from stored procedures
(coded in C), It works fine for smaller data?
And elog prints out the result nicely; but when the result is "returned" it
makes the server disconnect I use the standard Datum methods (actually
I've tried any
Curt Sampson wrote:
>
> On Tue, 23 Apr 2002, mlw wrote:
>
> > > On a system that has neither read-ahead nor sorting of I/O requests,
> > > yes. Which systems are you using that provide neither of these
> > > facilities?
> >
> > This only happens if the OS can organize the I/O requests in such a
At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote:
>This is an interesting point, that an index scan may fit in the cache
>while a sequential scan may not.
If so, I would expect that the number of pages read is significantly
smaller than it was with a sequential scan. If that's the case,
doesn't th
77 matches
Mail list logo
