On 7/26/06 10:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
An obvious deduction is that the TPCH dataset is much more amenable to
run compression than my synthetic Zipfian data was. The interesting
question is how well real datasets are run compressable,
Jie Zhang [EMAIL PROTECTED] writes:
On 7/26/06 10:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
... A nonuniform distribution would probably mean that some
of the bitmaps compress better-than-expected and others worse. I have
no idea how to model that and guess what the overall result is ...
The
On Jul 27, 2006, at 14:03 , Tom Lane wrote:
What we're talking about here is ways to specify the intended
usage with other units (eg I want N megabytes of shared buffers) but
that's not going to magically let you allocate half a shared buffer.
Peter's not said exactly how he plans to deal with
Tom Lane wrote:
It is. For instance shared_buffers is configured as the number of
buffers. What we're talking about here is ways to specify the
intended usage with other units (eg I want N megabytes of shared
buffers) but that's not going to magically let you allocate half a
shared buffer.
Bort, Paul wrote:
I still think it would be a good idea to use the standard, and that
this is an opportunity to do so.
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to the other
system, now would be the time to do
Am Mittwoch, den 26.07.2006, 16:58 -0400 schrieb Tom Lane:
Susanne Ebrecht [EMAIL PROTECTED] writes:
This is a cute hack, but it does only a small part of what I think the
spec says.
Thank you for compliment.
In the first place, the SQL syntax is pretty clear that you can combine
simple
Bruce Momjian [EMAIL PROTECTED] wrote:
The attached patch requires the new row to fit, and 10% to be free on
the page. Would someone test that?
This is another solution for the same purpose. We can avoid to call
PageIndexMultiDelete() to remove only one tuple. _bt_split() becomes
to ignore
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a warning or error in
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form, because you can
Good day for You.
I need to change password of the usuaryPOSTGRES using the commando "ALTER USER". This change I must do it by means of a program .bat in quiet way.
I have the following instruction in .bat program:
psql -S "ALTER USER postgres WITH PASSWORD 'xxtyod';"
But when I
Mónica Ivonne Herrera Alonso wrote:
Mónica,
I need to change password of the usuary POSTGRES using the commando ALTER
USER. This change I must do it by means of a program .bat in quiet way.
I have the following instruction in .bat program :
psql -S ALTER USER postgres WITH
On Sun, 2006-07-16 at 01:04 +0300, Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-14 kell 17:39, kirjutas Simon Riggs:
On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I've now thought about how to fix that without doing that rather
crude
Tom Lane wrote:
much anything that can generate a row. The patch as you have it
provides nothing more than syntactic sugar for something people can do
anyway. The reason people want this syntax is that they expect to be
able to write, say,
UPDATE mytab SET (foo, bar, baz) =
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
(SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
That UPDATE example is interesting because I remember when using
Informix that I had to do a separate SELECT statement for each UPDATE
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
UPDATE mytab SET (foo, bar, baz) =
(SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
That UPDATE example is interesting because I remember when using
Informix that I had to do a separate SELECT
I'm not sure exactly what to do here. I tried simply doing
CREATE TYPE cube;
But I still get NOTICE's to the effect of return type cube is only a
shell or argument type cube is only a shell.
I'm not sure how to do this to get zero NOTICES.
Advice appreciated.
Josh Reich
Tom Lane wrote:
Joshua Reich [EMAIL PROTECTED] writes:
I'm not sure exactly what to do here. I tried simply doing
CREATE TYPE cube;
But I still get NOTICE's to the effect of return type cube is only a
shell or argument type cube is only a shell.
Hmm ... I remembered that we'd discussed suppressing those
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I don't have time to do it for
8.2.
I get
Bort, Paul wrote:
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I don't have time
On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in
On Jul 27, 2006, at 9:16 AM, Bort, Paul wrote:
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I
All right, I give up. I guess no one seems to want to admit this is a
bad security policy, or accurately document it. Does that make it an
easter egg?
On Thu, Jul 20, 2006 at 01:59:43PM -0400, Bruce Momjian wrote:
OK, text again updated:
For schemas, allows access to objects
[snip]
Forcing people to use a specific casing scheme is just going to lead
to confusion and user frustration. If there's not a very solid
I guess nobody will force people to use the units at all.
*functional* argument for it, we shouldn't do it. Wanting to enforce
a convention that
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000 bytes instead of 1024
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
--
Peter Eisentraut
On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, T, 2006-07-25 kell 13:06, kirjutas Tom Lane:
The reason I have such high sales resistance is that we've
carried the
hash and rtree AMs for years, hoping that someone would do the
work to
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
I
On Thu, 2006-07-27 at 17:57, Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
Actually, -general would be the place. -hackers is for back-end hacking.
On Jul 26, 2006, at 1:18 PM, Redefined Horizons wrote:
Is this an appropriate place for questions about implementing user
defined functions and custom data types in the C programming language?
I didn't want to dirty the
On 7/26/06 11:50 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jie Zhang [EMAIL PROTECTED] writes:
On 7/26/06 10:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
... A nonuniform distribution would probably mean that some
of the bitmaps compress better-than-expected and others worse. I have
no idea how
On Jul 26, 2006, at 4:29 PM, Hannu Krosing wrote:
Well the desire for it comes from a very well established need
for dealing
with extremely large tales with relatively small hot spots. The
basic problem
being that currently the cost of vacuum is proportional to the
size of the
table rather
On Wednesday 26 July 2006 14:27, Darcy Buskermolen wrote:
On Wednesday 26 July 2006 14:03, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
The question though is if we did that, would Slony actually use it?
If it made sence to do it, then yes we would do it. The problem
Tom Lane wrote:
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form,
On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point
here is
that the existing vacuum does not rely on re-computing index keys; all
Peter Eisentraut wrote:
This consideration would become much more interesting if
*any* software
product actually made use of this newer proposed convention,
but so far
I haven't seen one yet.
So we'll look at it when Oracle does it?
I think we should be leading this charge, rather
Phil Frost wrote:
All right, I give up. I guess no one seems to want to admit this is a
bad security policy, or accurately document it. Does that make it an
easter egg?
I'm sure some people agree that there is a problem. It would help,
however, if you were not talking about two different
Bort, Paul wrote:
So we'll look at it when Oracle does it?
I didn't say Oracle, I said anyone. It could be Microsoft or Samba or
Red Hat or NetBSD or my VoIP phone.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
I'm sure some people agree that there is a problem. It would help,
however, if you were not talking about two different things at once.
And it would help if you actually proposed a change that would improve
matters.
What
Phil Frost wrote:
What two things are there?
Well, the subject says lastval exposes information that currval does
not while you are talking about schema permissions. I still don't
know what you're really after. One of your posts stated that you have
repeatedly demonstrated ways to overcome
Phil Frost wrote:
On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
I'm sure some people agree that there is a problem. It would help,
however, if you were not talking about two different things at once.
And it would help if you actually proposed a change that would
Jim Nasby wrote:
On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
What would be the use-case for hash indexes ? And what should be
done to make them faster than btree ?
If we knew, we'd do it ;-) But no one's put enough effort into it
to find out.
Peter Eisentraut wrote:
I didn't say Oracle, I said anyone. It could be Microsoft or
Samba or
Red Hat or NetBSD or my VoIP phone.
OK, I did some further digging, and
(http://members.optus.net/alexey/prefBin.xhtml) has a list at the end of
the page of software that the author claims use
I wrote:
I have applied this and made an attempt to fix
cube/expected/cube_1.out - we will still need to keep an eye on the
various cube tests.
It looks like with the current tests we will need at least one more
possible results file (gazelle and asp on buildfarm agree about negative
I think this will cause breakage for other people.
Right now I think the order is unique to AIX for some reason.
Recent buildfarm run of gazelle should have matched the -0 variant
(cube_1.out), but did not.
Also, what is worrisome is that there is an ORDER BY on the result set
that is failing
On Tuesday 25 July 2006 22:05, Marko Kreen wrote:
On 7/24/06, Nicolai Petri [EMAIL PROTECTED] wrote:
I'm in the need for my custom written replication engine to obtain the
current transaction id from a trigger function. As far as I'm told it's
not possible today. Would people object much
I am uncomfortable with the fact that the ordering is different on
different architectures. AFAIK, all I did was port the ordering function
from V0 to V1.
Short of me continually submitting patches until I fix it, is there an
easier way, or some pointers as to what I should be looking for in
Indeed. I am going to revert it.
The trouble is we currently have several orthogonal variations, which is
a worry on its own:
. negative zero
. exponent format, and
. result ordering
Looking closer, the result ordering certainly does seem odd, as you say.
Surely with ORDER BY it should be
I just updated to the latest HEAD, so I assume I have the cube_1.out
that you changed. If you look at the order of the results expected in
cube.out and cube_1.out, they are different. So I don't think we have a
problem with the code, we just need to fix the ordering in cube_1.out.
The same
Peter Eisentraut wrote:
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000
Mónica Ivonne Herrera Alonso wrote:
Hi,
However. I continued my instruction and follows without working to me.
Exists the way to invoke psql that is not of interactive way so that It
alters password of a user with no need to be in psql?
With the commando psql - S ALTER USER
it
Marc Munro [EMAIL PROTECTED] writes:
The attached patch provides add-ins with the means to register for
shared memory and LWLocks. This greatly improves the ease with which
shared memory may be used from add-ins, while blah blah blah
I have tried to be patient but this is my first patch
Alvaro Herrera [EMAIL PROTECTED] writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns it not into a feature, but into a gotcha.
I'm unconvinced that it's either a bug or
Just noticed these:
0 $ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
-I/pgsql//source/12vacuum/contrib/pgstattuple -I../../src/include
-I/pgsql//source/12vacuum/src/include -D_GNU_SOURCE -c -o
Joshua Reich wrote:
I just updated to the latest HEAD, so I assume I have the cube_1.out
that you changed. If you look at the order of the results expected in
cube.out and cube_1.out, they are different. So I don't think we have
a problem with the code, we just need to fix the ordering in
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns it not into a feature, but into a gotcha.
I'm unconvinced
Alvaro Herrera [EMAIL PROTECTED] writes:
Just noticed these:
Yeah, I complained about that before: the unportability is the least of
that code's problems. There's a patch in the queue that I trust fixes
it.
regards, tom lane
---(end of
On Thu, Jul 27, 2006 at 05:56:15PM +0200, Peter Eisentraut wrote:
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The
Jim Nasby [EMAIL PROTECTED] writes:
Even if we stopped right there it would still be a huge win in many (most?)
cases. How often do the indexes on a table comprise even 50% of the table's
size?
I would say they're usually roughly comparable actually. It depends on how
wide your table is
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to try to stress test the comparison routines a bit to
make sure they really are deterministic.
Eyeball inspection shows that cube_cmp is wrong: it's doing
PG_RETURN_INT16 where it should say PG_RETURN_INT32.
As best I can tell, the
Jim Nasby wrote:
On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
Susanne Ebrecht [EMAIL PROTECTED] writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to try to stress test the comparison routines a bit to
make sure they really are deterministic.
Eyeball inspection shows that cube_cmp is wrong: it's doing
PG_RETURN_INT16 where it should say PG_RETURN_INT32.
Jim Nasby [EMAIL PROTECTED] writes:
First, when it comes to page values, perhaps we should allow pages/
blocks as a valid unit. That would allow people who want to to
specify things in pages and still be explicit about what they mean.
Second, lack of interest or no, I feel forcing specific
Peter Eisentraut [EMAIL PROTECTED] writes:
... The question is whether we want to have kB mean
1000 bytes instead of 1024 bytes.
In my mind, that goes against current practice.
I concur. Most of the places where we are using these units, they are
for specifying memory sizes, and *everyone*
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I notice that cube_2.out hasn't been updated. Was that intentional?
Well, I was going to wait to see a buildfarm member that needed the
alternative exponent representation, and use the regression diff as a
template
I've had pretty
Martijn van Oosterhout kleptog@svana.org writes:
My main problem with the kibi, mibi, etc is that they're basically
unknown.
Frankly the main problem is that they're idiotic.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of
Yippee!
---BeginMessage---
Log Message:
---
Aggregate functions now support multiple input arguments.
...
Original patch by Sergey Koposov; review, documentation, simple regression
tests, pg_dump and psql support by moi.
---End Message---
--
Gregory Stark
EnterpriseDB
Tom Lane wrote:
+1 on both of those. I think that pg_settings should actually show
pages as the native unit for shared_buffers et al. The current
8kb display isn't a valid unit --- consider what happens if a
program does select setting || unit from pg_settings ...
Physicists know that the
Sergey's recent patch for the SQL2003 binary aggregates implements each
of them three times: in float4, float8, and numeric arithmetic. This
seems like vast overkill. The float4 versions certainly ought to go,
as they won't perform noticeably better than float8 and will likely be
subject to
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on both of those. I think that pg_settings should actually show
pages as the native unit for shared_buffers et al. The current
8kb display isn't a valid unit --- consider what happens if a
program does select setting || unit from
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hannu Krossing asked me about his patch to ignore transactions running
VACUUM LAZY in other vacuum transactions. I attach a version of the
patch updated to the current sources.
nonInVacuumXmin seems useless ... perhaps a vestige
Ühel kenal päeval, N, 2006-07-27 kell 19:29, kirjutas Alvaro Herrera:
We could either add it anew, beside nonInVacuumXmin, or replace
nonInVacuumXmin. The difference will be whether we will have something
to be used to vacuum shared relations or not. I think in general,
shared relations
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
version of the computation?
Hmm, not useless at all really -- only a bug of mine. Turns out the
notInVacuumXmin stuff is essential, so I put it back.
Uh, why?
I
On Thu, Jul 27, 2006 at 04:40:45PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns it not into a feature,
On Thu, Jul 27, 2006 at 05:01:37PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns
* Phil Frost ([EMAIL PROTECTED]) wrote:
Granted, I can't think of too many ways one could store sensitive
information in a sequence. I think it's more important to consider what
it implies about the system behind the issue. When I revoke some
privilege, I expect it to be enforced regardless of
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Alvaro:
In effect I published the file pgpass.conf and I added the following line:
localhost:5432:*:postgres:kklliu
However. I continued my instruction and follows without working to me. Exists the way to invoke psql that is not of interactive way so that It alters password of a user
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
version of the computation?
Hmm, not useless at all really -- only a bug of mine. Turns out the
notInVacuumXmin stuff is essential, so I put it
On Jul 28, 2006, at 12:37 , ISHIDA Akio wrote:
| SJIS サーバの符号化方式としてはサポートしていません。
Just to confirm, it does look like there's a discrepancy between what
is in the documentation and the actual behavior of the server. The
documentation indicates that SJIS is a valid server encoding:
80 matches
Mail list logo
