On Thu, 28 Nov 2002 21:46:09 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred suggested a separate log file (pg_subclog or some such) but
I really don't see any operational advantage to that. You still end up
with 4 bytes per transaction, you're just assuming that putting them
in a different file
On 28 Nov 2002 11:34:49 -0500
Rod Taylor [EMAIL PROTECTED] wrote:
Force the system to use it as a function.
select current_user();
On Thu, 28 Nov 2002 17:20:59 -0500
Tom Lane [EMAIL PROTECTED] wrote:
As for some current_*** functions, select current_user; seems to
work, but select
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to put on this system. It might make sense to say allow upto X
On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
This is almost certainly a bad idea. vacuum is not very
processor-intensive, but it is disk-intensive. Multiple vacuums running
On Friday 29 November 2002 00:56, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
But we already have a recycling mechanism for pg_clog. AFAICS,
creating a parallel log file with a separate recycling mechanism is
a study in wasted effort.
But that recycling
Manfred Koizar [EMAIL PROTECTED] writes:
1) If your site/instance/application/whatever... does not use nested
transactions or does use them only occasionally, you don't have to pay
the additional I/O cost.
As I already said to Bruce, designing this facility on the assumption
that it will be
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Right now AVD only performs vacuum analyze on specific tables as it deems they
need it, it does not perform vacuum on entire databases at any point yet.
See
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/routine-vacuuming.html
However
Manfred Koizar wrote:
One more argument for pg_subtrans being visible to all backends: If
an UPDATE is about to change a tuple touched by another active
transaction, it waits for the other transaction to commit or abort.
We must always wait for the main transaction, not the subtrans.
This
At 09:58 PM 11/28/02 -0500, you wrote:
Hm. Are we sure that both versions were built with the same
optimization level, etc? (My private bet is that Wade's 7.2 didn't
have multibyte or locale support --- but that's a long shot when we
don't know the datatypes of the columns being joined on...)
I noticed that the system is really pretty shaky about how it chooses
the datatype-specific operators to implement sorting and grouping.
In the GROUP BY case, for example, the parser looks up an operator
named '' for the column datatype, and then sometime later the executor
looks up an operator
You can't, at least not until 7.4. You can compile the interfaces like
libpq and the binary psql. See win32.mak for that.
---
Prasanna Phadke wrote:
Can anybody explain me, how to compile postgres source code in VC++.
By chance I just noticed that lseg equality is coded as
Datum
lseg_eq(PG_FUNCTION_ARGS)
{
LSEG *l1 = PG_GETARG_LSEG_P(0);
LSEG *l2 = PG_GETARG_LSEG_P(1);
PG_RETURN_BOOL(FPeq(l1-p[0].x, l2-p[0].x)
FPeq(l1-p[1].y, l2-p[1].y)
Hi guys,
Just out of interest, if someone was going to pay you to hack on Postgres
for 6 months, what would you like to code for 7.4?
My ones are:
* Compliant ADD COLUMN
* Integrated full text indexes
* pg_dump dependency ordering
What would you guys do? Even if it isn't feasible right now...
Looks like the eWeek article has been published:
http://www.eweek.com/article2/0,3959,732789,00.asp
Sorry for sounding like such a dork :)
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On Thu, 28 Nov 2002 12:59:21 -0500 (EST), Bruce Momjian
[EMAIL PROTECTED] wrote:
Yes, locking is one possible solution, but no one likes that. One hack
lock idea would be to create a subtransaction-only lock, [...]
[...] without
having to touch the xids in the tuple headers.
Yes, you could do
Tom Lane wrote:
By chance I just noticed that lseg equality is coded as
Datum
lseg_eq(PG_FUNCTION_ARGS)
{
LSEG *l1 = PG_GETARG_LSEG_P(0);
LSEG *l2 = PG_GETARG_LSEG_P(1);
PG_RETURN_BOOL(FPeq(l1-p[0].x, l2-p[0].x)
FPeq(l1-p[1].y, l2-p[1].y)
There isn't one!
Chris
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Manfred Koizar [EMAIL PROTECTED] writes:
Visibility check by other transactions: If a tuple is visited and its
XMIN/XMAX_IS_COMMITTED/ABORTED flags are not yet set, pg_clog has to
be consulted to find out the status of the inserting/deleting
transaction xid. If pg_clog[xid] is ...
On Fri, 29 Nov 2002 13:33:28 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Unfortunately this discussion is wrong. User-level visibility checks
will usually have to fetch the parentxid in case 01 as well, because
even if the parent is committed, it might not be visible in our
snapshot.
Or we don't
Manfred Koizar wrote:
On Fri, 29 Nov 2002 13:33:28 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Unfortunately this discussion is wrong. User-level visibility checks
will usually have to fetch the parentxid in case 01 as well, because
even if the parent is committed, it might not be visible in
Tom,
I'm just curious, will your proposed in/exists optimizations help for
queries like:
db=# explain delete from dns_expired_domains where domain_id in (select
domain_id from dns_expired_domains group by domain_id having count(*)=14
);
NOTICE: QUERY PLAN:
Seq Scan on dns_expired_domains
Christopher Kings-Lynne wrote:
There isn't one!
Chris
No kidding. I propose changes to the following pages:
http://www14.us.postgresql.org/: Prominent mention of the latest
stable and unstable releases (just stable now, of course). But since
this seems to be kind of a repeat of the news
Mike Benoit [EMAIL PROTECTED] writes:
I'm just curious, will your proposed in/exists optimizations help for
queries like:
db=# explain delete from dns_expired_domains where domain_id in (select
domain_id from dns_expired_domains group by domain_id having count(*)=14
);
Probably, but I'm
Manfred Koizar [EMAIL PROTECTED] writes:
Maybe. The whole point of my approach is: If we can limit the active
range of transactions requiring parent xid lookups to a small fraction
of the range needing pg_clog lookups, then it makes sense to store
status bits and parent xids in different
I am concerned this is getting beyond my capabilities for 7.4 --- anyone
want to help?
---
Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
Maybe. The whole point of my approach is: If we can limit the active
On Fri, 2002-11-29 at 13:22, Tom Lane wrote:
Mike Benoit [EMAIL PROTECTED] writes:
I'm just curious, will your proposed in/exists optimizations help for
queries like:
db=# explain delete from dns_expired_domains where domain_id in (select
domain_id from dns_expired_domains group by
Christopher Kings-Lynne wrote:
Hi guys,
Just out of interest, if someone was going to pay you to hack on Postgres
for 6 months, what would you like to code for 7.4?
Replication. Replication. Replication. Replication. Replication.
Replication. Replication. Replication. Replication. Replication.
Christopher Kings-Lynne kirjutas R, 29.11.2002 kell 23:51:
Hi guys,
Just out of interest, if someone was going to pay you to hack on Postgres
for 6 months, what would you like to code for 7.4?
My ones are:
* Compliant ADD COLUMN
* Integrated full text indexes
* pg_dump dependency
pg_dump, our upgrade process is painful enough having to do a dump, reload.
I think we should be able to guarantee (or at least let much closer to it)
that the process works in all cases.
Personally pg_upgrade would be even nicer.
- Original Message -
From: Christopher Kings-Lynne [EMAIL
At 10:51 AM 29/11/2002 -0800, Christopher Kings-Lynne wrote:
* pg_dump dependency ordering
I've actually started working on pg_dump in the background, but if you want
to do it let me know.
In terms of things I would like to see:
- background/integrated vacuum (not just an overwriting storage
At 04:56 PM 29/11/2002 -0800, Christopher Kings-Lynne wrote:
- COPY TO/FROM with a list of columns (maybe we have it?) - it's useful
for
making metadata changes then reloading data (Inserts are much slower).
We do already have it in 7.3:
Excellent. Then I just need to add support in
Wow Hannu - your list puts mine to shame!
Application server support
* better XML integration
- XML(*) aggregate function returning XML representation of subquery
- XML input/output to/from tables
- XML searchable/indexable in fields)
I've had thoughts
Christopher Kings-Lynne writes:
There isn't one!
Has there been a release? It certainly hasn't been announced in the usual
places that I monitor.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our
Comment in {identifier} section in src/backend/parser/scan.l states:
[...]
* Note: here we use a locale-dependent case conversion,
* which seems appropriate under SQL99 rules, whereas
* the keyword comparison was NOT
At 05:33 PM 29/11/2002 -0800, Christopher Kings-Lynne wrote:
Hmmm. I could have sworn that someone (Neil?) already did that?
Not AFAICT - at least based on looking at the manual. I'll check the code.
Philip Warner
On Fri, 29 Nov 2002, Christopher Kings-Lynne wrote:
Glad you liked it. But that doesn't change the fact that it obscured the
release to the point that many people didn't even know it was released.
I found out by folks complaining about broken links.
Hrm - the subject said it all, plus
- Original Message -
From: Peter Eisentraut [EMAIL PROTECTED]
To: Christopher Kings-Lynne [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 29, 2002 4:16 PM
Subject: Re: [HACKERS] Postgres 7.3 announcement on postgresql.org
Christopher Kings-Lynne writes:
There isn't
Tom Lane writes:
What I'm thinking of doing instead is always looking up the = operator
by name, and accepting this as actually being equality if it is marked
mergejoinable or hashjoinable or has eqsel() as its restriction
selectivity estimator (oprrest). If we are looking for a operator
Christopher Kings-Lynne writes:
It has been announced on the announce mailing list and in the eweek
article... It's downloadable from the advocacy site...
Yeah, that'll let the world know.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
On 29 Nov 2002, Ryan Mahoney wrote:
Scroll down and read the rest of, it's an excellent announcement! If
the website and mirrors made mention of the release (as of 8:19PM CST
they don't!) and the message was sent to all the mailing lists, there
would probably be less confusion. When I read
Peter Eisentraut [EMAIL PROTECTED] writes:
Has there been a release? It certainly hasn't been announced in the usual
places that I monitor.
Marc claimed he'd put out the announcement on pgsql-announce, but that
copy of the message never arrived here (it did show up on pgsql-general
though).
Peter Eisentraut [EMAIL PROTECTED] writes:
Has there been a release? It certainly hasn't been announced in the
usual
places that I monitor.
Marc claimed he'd put out the announcement on pgsql-announce, but that
copy of the message never arrived here (it did show up on pgsql-general
Peter Eisentraut [EMAIL PROTECTED] writes:
My first thought is that this seems to be an awefully backwards way to
define operator semantic metadata.
Why? The property we are interested in is that two operators '' and
'=' will work for grouping --- ie, if you order by '' and then combine
On Fri, 29 Nov 2002, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Has there been a release? It certainly hasn't been announced in the usual
places that I monitor.
Marc claimed he'd put out the announcement on pgsql-announce, but that
copy of the message never arrived here
Marc claimed he'd put out the announcement on pgsql-announce, but that
copy of the message never arrived here (it did show up on pgsql-general
though). Evidently you and Vince never got it either ...
After alot of searching I did find it. It wasn't exactly what one would
expect a
On Fri, 29 Nov 2002, Christopher Kings-Lynne wrote:
Marc claimed he'd put out the announcement on pgsql-announce, but that
copy of the message never arrived here (it did show up on pgsql-general
though). Evidently you and Vince never got it either ...
After alot of searching I did
Glad you liked it. But that doesn't change the fact that it obscured the
release to the point that many people didn't even know it was released.
I found out by folks complaining about broken links.
Hrm - the subject said it all, plus what about the first 2 paragraphs?
PostgreSQL Global
FYI, Vince, I started reading all my email (using elm) in a special 120
column wide, 38 row xterm. There was just too much detail in those
subjects i was missing.
---
Vince Vielhaber wrote:
On Fri, 29 Nov 2002,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The archives for the following mailing lists appear to
have two identical links to November 2002:
admin
advocacy
announce
bugs
cygwin
Here's one of them:
http://archives.postgresql.org/pgsql-announce/
Greg Sabino Mullane [EMAIL PROTECTED]
PGP
On Fri, 29 Nov 2002, Bruce Momjian wrote:
FYI, Vince, I started reading all my email (using elm) in a special 120
column wide, 38 row xterm. There was just too much detail in those
subjects i was missing.
Doesn't do me much good if too often I don't have the luxury of a large
screen 'cuze
Vince Vielhaber wrote:
On Fri, 29 Nov 2002, Bruce Momjian wrote:
FYI, Vince, I started reading all my email (using elm) in a special 120
column wide, 38 row xterm. There was just too much detail in those
subjects i was missing.
Doesn't do me much good if too often I don't have the
On Sat, 30 Nov 2002, Justin Clift wrote:
Vince Vielhaber wrote:
On Fri, 29 Nov 2002, Bruce Momjian wrote:
FYI, Vince, I started reading all my email (using elm) in a special 120
column wide, 38 row xterm. There was just too much detail in those
subjects i was missing.
Nicolai Tufar [EMAIL PROTECTED] writes:
So I have changed lower-case conversion code in scan.l to make it purely
ASCII-based.
as in keywords.c. Mini-patch is given below.
Rather than offering a patch, you need to convince us why our reading of
the SQL standard is wrong. (Oracle does it that
Tom Lane wrote:
I've been thinking about how to improve the performance of queries using
WHERE x IN (subselect) and WHERE x NOT IN (subselect).
In the existing implementation, the subquery result is rescanned to look
for a match to x each time the WHERE clause is executed; this essentially
makes
Vince Vielhaber wrote:
snip
Yes it would. But while on the subject, why did you only mention it's
availability being on the advocacy site?
*We* mentioned it's availability being on the Advocacy site, because it
gives people a single place to go that has both PostgreSQL itself *and*
a site
Joe Conway wrote:
Tom Lane wrote:
I've been thinking about how to improve the performance of queries using
WHERE x IN (subselect) and WHERE x NOT IN (subselect).
How about starting with a rule-based method to make the choice?
1. If uncorrelated: use hash-based approach - ISTM this might
Mike Mascari [EMAIL PROTECTED] writes:
I curious if any of the rewriting of EXISTS and NOT EXISTS would
address the problem described by Date:
http://www.firstsql.com/iexist.htm
We are not here to redefine the SQL spec ... and especially not to
eliminate its concept of NULL, which is what
On Fri, Nov 29, 2002 at 10:51:26AM -0800, Christopher Kings-Lynne wrote:
Just out of interest, if someone was going to pay you to hack on Postgres
for 6 months, what would you like to code for 7.4?
Well, nobody is paying me, but I want to
- fix the btree problem leaking unused pages (I think
By no means I would try to convince that your reading of
the SQL standards is wrong. What I am trying to tell is
that Turkish alphabet is broken beyond repair. And since
there is absolutely no way to change our alphabet, we
may can code a workaround in the code.
So i do not claim that your code
59 matches
Mail list logo
