Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have updated the release notes for 7.4.1 and HISTORY as of Dec
14. I will make further adjustments before the 7.4.1 release.
Would you care to put back the correct upgrade instructions that I
had written there?
BPeter Eisentraut wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have updated the release notes for 7.4.1 and HISTORY as of Dec
14. I will make further adjustments before the 7.4.1 release.
Would you care to put back the correct upgrade instructions
Jan Wieck [EMAIL PROTECTED] writes:
If you want to prevent accidential access, start postmaster on a
non-standard port.
... thus making pg_upgrade subject to all sorts of interesting questions
about whether particular ports get filtered by kernel iptables rules?
This doesn't seem like a really
Alvaro Herrera [EMAIL PROTECTED] writes:
BTW, what happened to the $QUOTE$ quoting idea? Was it applied, or
even developed?
I'd like to see it done for 7.5, but haven't personally had time to go
further than the proof-of-concept backend patch I posted awhile ago.
I think the minimum amount of
On Tue, Dec 16, 2003 at 07:00:25PM -0500, Bruce Momjian wrote:
Are you saying some programs will look in /usr/include before looking in
-I specified directories, and that is the whole problem? If so, that is
100% wrong and we don't have to fix our files to workaround this.
No I meant to say
I'm working on a pljava module. In it, I'd like to cache some allocated
structures (allocated using TopMemoryContext) using a string as the key. I
need a hash or binary-search table with dynamic size where I can store
arbitrary structures and then find them using strings. Typical size is less
than
Tom Lane wrote:
I think the minimum amount of additional work that has to be done before
we can apply it is to teach psql's input parser about $QUOTE$ ---
without that, the feature is not only useless but counterproductive.
IMHO it's not useless. pgAdmin already knows that quoting scheme...
On Wed, Dec 17, 2003 at 10:27:19AM -0500, Bruce Momjian wrote:
Are you suggesting moving the ecpg files into pgsql/include/ecpg? Do we
know that no one using ecpg is going to be including a /usr/include file
that needs /usr/include/xxx.h?
No, just the files needed for Informix compatibility.
Andreas Pflug wrote:
Tom Lane wrote:
I think the minimum amount of additional work that has to be done before
we can apply it is to teach psql's input parser about $QUOTE$ ---
without that, the feature is not only useless but counterproductive.
IMHO it's not useless. pgAdmin already knows
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that psql/mainloop.c contains this comment:
* FIXME: rewrite this whole thing with flex
Is now the time to do that?
If you feel like giving it a shot, ain't nobody gonna stand in your way.
MainLoop() is well past the level of unmaintainability
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that psql/mainloop.c contains this comment:
* FIXME: rewrite this whole thing with flex
Is now the time to do that?
If you feel like giving it a shot, ain't nobody gonna stand in your way.
MainLoop() is well past the level of
Hi,
while trying to create a query this afternoon dealing with intervals, I
noticed the following behaviour and I wondered, if it is intended. (It was
non-intuitive to me and if there was a warning in the docs i missed it.)
The lines marked --- make me wonder ...
tschwarz= select
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
while some thing are still in psql TODO list, I'm interested in
following...
I'd like to know when are you planning to deal with this TODO item:
Allow
Marko Zmak wrote:
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
while some thing are still in psql TODO list, I'm interested in
following...
I'd like to know when are you planning to deal with
On Wed, 17 Dec 2003, Bruce Momjian wrote:
Marko Zmak wrote:
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
while some thing are still in psql TODO list, I'm interested in
following...
I'd
--On Thursday, December 18, 2003 08:07:03 +1100 Gavin Sherry
[EMAIL PROTECTED] wrote:
On Wed, 17 Dec 2003, Bruce Momjian wrote:
Marko Zmak wrote:
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
Michael Fuhr [EMAIL PROTECTED] writes:
When a client connects to the database server using a service name,
the dbname parameter in pg_service.conf is ignored. In the absence
of an explicitly-named database in the connection string, the service
name is used as the database name regardless of
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
When a client connects to the database server using a service name,
the dbname parameter in pg_service.conf is ignored. In the absence
of an explicitly-named database in the connection string, the service
name is used as the database
Tilo Schwarz [EMAIL PROTECTED] writes:
while trying to create a query this afternoon dealing with intervals, I
noticed the following behaviour and I wondered, if it is intended.
tschwarz= select '-1'::interval;
interval
--
-01:00---
(1 row)
This appears to be
Marko Zmak wrote:
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
while some thing are still in psql TODO list, I'm interested in
following...
I'd like to know when are you planning to deal with
Tom Lane [EMAIL PROTECTED] writes:
Tilo Schwarz [EMAIL PROTECTED] writes:
tschwarz= select '-0.1'::interval;
interval
-
00:00:00.10 ---
(1 row)
This is incontestably a bug. Will fix for 7.4.1.
I've applied the attached patch to 7.4 and HEAD. It'd probably work in
7.3 as
I'm curious if anyone has ever looked into adding OLAP functionality (per
the SQL99 specs) into PostGreSQL. I don't actually own the proper SQL99
specifications, and since the newer sql2003 ones are coming out I don't know
which to purchase. Could someone point me in the right direction? I've
Jonathan Gardner wrote:
Marko Zmak wrote:
I've been usin psql for quite a long time and I found it to be very
comfortable. Since some web providers in my country refuse to put psql
while some thing are still in psql TODO list, I'm interested in
following...
I'd like to know when are you
Robert Bedell [EMAIL PROTECTED] writes:
I'm curious if anyone has ever looked into adding OLAP functionality (per
the SQL99 specs) into PostGreSQL.
There was a fairly crude CUBE implementation submitted (and rejected) a
few months ago, but there's not been any work I thought had a chance of
Robert Bedell wrote:
I'm curious if anyone has ever looked into adding OLAP functionality (per
the SQL99 specs) into PostGreSQL. I don't actually own the proper SQL99
specifications, and since the newer sql2003 ones are coming out I don't know
which to purchase. Could someone point me in the
Andrew Dunstan [EMAIL PROTECTED] writes:
case 6 - limit all users' connections regardless of database:
limit all all n
That's called max_connections. Don't think we need a redundant
implementation of same ...
Another little nitpick is that I don't like assuming that any and
all are never
Andrew Dunstan wrote:
Before we even get there we need agreement on exactly what it means :-)
Seems like the best place for the settings might be pg_hba.conf.
Say we have a new keyword limit there. Here are the possibilities (I
think):
snip
First post (unlurking) here, so just a minor
More specifically I would like to add grouping sets, and the CUBE and
ROLLUP
operators, into postgresql. Since modifying such the GROUP BY operation
would necessitate changing the query structure, wouldn't that affect the
query rewrites and genetic optimizer?
I don't think either the
-*- Tom Lane [EMAIL PROTECTED] [ 2003-12-17 22:46 ]:
Andrew Dunstan [EMAIL PROTECTED] writes:
case 6 - limit all users' connections regardless of database:
limit all all n
That's called max_connections. Don't think we need a redundant
implementation of same ...
Another little nitpick
David Felstead wrote:
Andrew Dunstan wrote:
Before we even get there we need agreement on exactly what it means :-)
Seems like the best place for the settings might be pg_hba.conf.
Say we have a new keyword limit there. Here are the possibilities (I
think):
snip again
Bah, what a way to
Tom Lane kirjutas N, 18.12.2003 kell 00:27:
Robert Bedell [EMAIL PROTECTED] writes:
I'm curious if anyone has ever looked into adding OLAP functionality (per
the SQL99 specs) into PostGreSQL.
As a first project one could think of implementing NULLS FIRST/LAST
(from 4.14.9) for all ORDER BY
Robert Bedell kirjutas N, 18.12.2003 kell 01:02:
These are not simple projects, I know.
Might be a tad ambitious for your first venture into backend hacking...
I agree completely. I'm not purporting to jump in quite that quickly, but
it is something I would like to see added, and am
I guess that by adding hash aggregates Tom solved most problems of
adding ROLLUP, CUBE and GROUPING SETS.
OTOH, I'm not sure if hash aggregates can already spill to disk if not
enough memory is available for keeping them all. If not, then adding
this capability would be great push towards
Robert Bedell kirjutas N, 18.12.2003 kell 01:55:
I guess that by adding hash aggregates Tom solved most problems of
adding ROLLUP, CUBE and GROUPING SETS.
OTOH, I'm not sure if hash aggregates can already spill to disk if not
enough memory is available for keeping them all. If not, then
it seems that the longest GROUPING SET and all its left-continuous
subsets could be collected from the sorted scan and the rest from hash
aggregates.
GROUPING SET () will always need a hash ;)
To optimise any further would require use of statistics data, and is
probably not a good idea
For pure ROLLUP one could shortcut the split-into-groups and
put-together-again process, as ROLLUP is already doable from single
sorted scan.
Actually as long as the grouping sets are all left-continuous of the
longest
grouping set it's doable from a single sorted scan. If done with
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] writes:
case 6 - limit all users' connections regardless of database:
limit all all n
That's called max_connections. Don't think we need a redundant
implementation of same ...
no - this was intended to limit *each* user - max-connections
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 17 December 2003 2:59 pm, David Felstead wrote:
David Felstead wrote:
Bah, what a way to make an entrance - I re-read Andrew's post and
realised he was talking about pg_hba.conf. My apologies. :(
Regardless, is this something that
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane said:
On an implementation level, where are you thinking of enforcing this?
Without digging deeply at all I thought probably in the postmaster.
Nah, that's a nonstarter, because the postmaster has basically no
information about its children
Hannu Krosing [EMAIL PROTECTED] writes:
OTOH, I'm not sure if hash aggregates can already spill to disk if not
enough memory is available for keeping them all.
They do not, which is something it'd be good to fix, since if the
planner drastically underestimates the number of groups, you could
Ideally that path isn't taken very often. But I'm currently having a
discussion off-list with a CMU student who seems to be seeing a case
where it happens a lot. (She reports that both WALWriteLock and
WALInsertLock are causes of a lot of process blockages, which seems to
mean that a lot
Jonathan Gardner [EMAIL PROTECTED] writes:
- -- Group www can only have 12 concurrent connections with the cluster.
ALTER GROUP www SET max_connections = 12;
I think group-related restrictions would be an impossible rat's nest
to define, because there's no one-to-one correspondence between
Þórhallur Hálfdánarson said:
I'd like to mention that administrators likely to use the this feature
would probably like to be able to tune this without having to modify a
file -- updating via SQL (= storing this in a system table) would be
extremely nice...
We set connection permissions in
On Wed, Dec 17, 2003 at 08:30:11PM -0500, Tom Lane wrote:
Jonathan Gardner [EMAIL PROTECTED] writes:
- -- Group www can only have 12 concurrent connections with the cluster.
ALTER GROUP www SET max_connections = 12;
I think group-related restrictions would be an impossible rat's nest
to
Alvaro Herrera [EMAIL PROTECTED] writes:
What about roles? Is anybody going to attack the mixed users+groups
implementation in this development cycles?
Not me. I think Peter was making some noises about it though.
regards, tom lane
---(end of
I have put up a list of projects being worked on and their TODO lists in
hope that people will find it easier to work on them:
http://momjian.postgresql.org/main/writings/pgsql/project
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
On Wed, 17 Dec 2003, Tom Lane wrote:
Jonathan Gardner [EMAIL PROTECTED] writes:
- -- Group www can only have 12 concurrent connections with the cluster.
ALTER GROUP www SET max_connections = 12;
I think group-related restrictions would be an impossible rat's nest to
define, because
Marc G. Fournier [EMAIL PROTECTED] writes:
On Wed, 17 Dec 2003, Tom Lane wrote:
I think group-related restrictions would be an impossible rat's nest to
define, because there's no one-to-one correspondence between backend
processes and groups.
'k, I'm a bit confused here ... we already do the
Patch applied. Thanks.
---
Sailesh Krishnamurthy wrote:
Hackers
Here is the definition of relation_byte_size() in optimizer/path/costsize.c:
--
Hannu Krosing [EMAIL PROTECTED] writes:
OTOH, I'm not sure if hash aggregates can already spill to disk if not
enough memory is available for keeping them all.
They do not, which is something it'd be good to fix, since if the
planner drastically underestimates the number of groups, you
Robert Bedell [EMAIL PROTECTED] writes:
1) When does the optimizer set the nodeAgg plan to HASHED?
See grouping_planner() in src/backend/optimizer/plan/planner.c
particularly the logic around use_hashed_grouping.
2) What mechanism would be best to use for storing the data on disk? I know
Thanks for the pointers!
The documentation points to the
'sort_mem' parameter for this, but the code doesn't look to actually
implement that yet.
Well, yeah, that's sort of exactly the point ... it's considered during
planning but the executor code has no fallback if the planner
Also ...
Robert Bedell [EMAIL PROTECTED] writes:
... I think that LookupTupleHashEntry
is the best place to put the code to spill over unto disk, since that is
used only by the Group, Agg, and Subplan executor nodes.
That's the right area to be looking at, but I don't think you can expect
to
That's the right area to be looking at, but I don't think you can expect
to do a decent job with localized hacking in LookupTupleHashEntry. That
function's API is predicated on the assumption that you have random
access to any entry in the hash table --- which stops being true as soon
as you
54 matches
Mail list logo
