Bruce Momjian wrote:
Tom Lane wrote:
Don't hold your breath ... 7.4.2 was only a couple weeks ago, and there
are no critical bugs in the CVS logs at this point.
The only post-7.4.2 Solaris fixes I can think of are for threaded
builds. Do you use those? If so, you can grab CVS
hi,
we can create table using LIKE syntax , so i think we could create type
with LIKE, its quite this same, ??
bye
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Sun, 28 Mar 2004, Matthew T. O'Connor wrote:
There are some pg_autovacum fixes, most serious being the one that
causes it to vacuum large tables far too often. I know it's a contrib
module, but does seem to be getting used a lot.
Good reason why it *should* be in GForge/GBorg ...
Hello all,
Can anyone point me to where in the code does Postgres Flush all the
Data to disk???
When XLogFlush is called, it only flushes the XLOG to disk, right? Does
the entire Data get flushed at the same time as the Log?
Thanks,
Diego
---(end of
I've been looking at the planner performance problem exhibited by
Eric Brown:
http://archives.postgresql.org/pgsql-performance/2004-03/msg00273.php
While a nine-way join is inherently going to take some time to plan
(if you don't constrain the search space with JOIN), it seemed to me
that this
Diego Montenegro wrote:
Hello all,
Can anyone point me to where in the code does Postgres Flush all the
Data to disk???
When XLogFlush is called, it only flushes the XLOG to disk, right? Does
the entire Data get flushed at the same time as the Log?
in src/backend/storage/smgr/md.c, mdsync():
Tom Lane wrote:
I've been looking at the planner performance problem exhibited by
Eric Brown:
http://archives.postgresql.org/pgsql-performance/2004-03/msg00273.php
While a nine-way join is inherently going to take some time to plan
(if you don't constrain the search space with JOIN), it seemed to
Mike Mascari [EMAIL PROTECTED] writes:
Tom Lane wrote:
I found that this reduced the planning time of Eric's
query by about 40%, without changing the resulting plan.
More great news, as always. IIRC you recently bumped the default
GEQO threshold from eleven to twelve. With your new fuzzy
Tom Lane wrote:
As an experiment, I made the attached patch that converts add_path's
cost comparisons to fuzzy comparisons --- two paths are considered to
have the same cost if it differs by less than 1% of the smaller
total_cost. I found that this reduced the planning time of Eric's
query by
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
+* XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
I'd want to see some evidence that there's use in twiddling it ...
in my initial test, setting it to 10% instead of 1% didn't seem
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
It looks like a great idea to me...
+ * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very
How hard would it be to add this:
The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set
The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set PG to do this, but that
should
Neil Conway wrote:
On 28-Mar-04, at 8:32 PM, Joe Conway wrote:
+ * XXX does this percentage need to be user-configurable?
...but I think the answer to the above is yes.
Is this really a parameter that we can expect administrators to be able
to understand and tune very effectively?
I think
Tom Lane wrote:
The reason these are all being kept is that add_path() will keep paths
of the same ordering (same pathkeys) if they rank differently on startup
cost than they do on total cost. Now that's a good rule in the
abstract, but a human looking at these numbers would certainly say
I don't have the original thread in my inbox anymore, so for reference:
http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF
-8selm=20129.1074484755%40sss.pgh.pa.us
Tom Lane last said:
I have committed a patch into CVS HEAD --- give it a try.
It took me awhile, but I finally got around to
Bruce Momjian [EMAIL PROTECTED] writes:
Do we know in the optimizer whether we will be needing cheapest startup
or not?
No. Higher levels might want either.
Is the middle one kept because the optimizer has to mix the startup plus
some percentage of the total cost for queries using LIMIT?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we know in the optimizer whether we will be needing cheapest startup
or not?
No. Higher levels might want either.
Is the middle one kept because the optimizer has to mix the startup plus
some percentage of the total cost for
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Right. There are potentially some ranges of LIMIT for which it could
win, I believe.
What if we take the total cost and divide it by the number of rows returned ---
then we have a per-row cost for each plan. Then we subtract the two,
Dear hackers,
I'm wondering for the rationnal of the types used in various tables in
pg_catalog (v 7.4.2) so as to represent the very same thing:
- in pg_index, the indkey is represented by a int2vector
- in pg_constraint, conkey and confkey are represented my smallint[]
As I was trying to
20 matches
Mail list logo
