> 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
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 expe
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 planne
"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
> 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 group
Patch applied. Thanks.
---
Sailesh Krishnamurthy wrote:
>
> Hackers
>
> Here is the definition of relation_byte_size() in optimizer/path/costsize.c:
>
> --
"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 alr
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, becau
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]
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
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 ne
Þó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 permissi
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 b
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
"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 chil
-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 th
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-conne
> > 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 do
> 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 go
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
> 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 towa
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
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 OR
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):
>
Bah, what a way
-*- 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 li
> > 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 e
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):
First post (unlurking) here, so just a minor con
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 nev
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 righ
"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 o
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 plann
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
lo
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
> 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
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
--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
>
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...
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
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 limit
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 version(
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
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 unmaintainabilit
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 th
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
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 that
> 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 l
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
Michael Meskes wrote:
> 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 worka
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... not
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
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
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
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 r
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 up
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 writt
55 matches
Mail list logo
