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 com
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 th
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 t
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 LIMI
I don't have the original thread in my inbox anymore, so for reference:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF
-8&selm=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
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
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
"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 prob
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
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 effect
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
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 ab
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 ne
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 m
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():
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 par
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 broadcast)
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 ...
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]
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 REL7_4_STAB
20 matches
Mail list logo
