> > > > So are whole pages stored in rollback segments or just
> > > > the modified data?
> > >
> > > This is implementation dependent. Storing whole pages is
> > > much easy to do, but obviously it's better to store just
> > > modified data.
> >
> > I am not sure it is necessarily better. Seem
Hi,
I need to implement a cache for query plans as part of my BSc thesis. Does
anybody know what happened to Karel Zak's patch?
I'm also looking for some comments & tips about how to implement a cache for
query plans and how to deal with the implementation of shared memory in
PSQL.
Greetings,
R
Tom, with all the work you've been doing inside planner and optimizer, has
there been anything done for 7.1.2 to make how a query is written cause
the backend to be more intelligent?
I'm playing with a query that I just don't like, since its taking ~3min to
run ...
It started as:
EXPLAIN SELEC
I'm trying to centralize data in a unique db, like it:
--- --- ---
|DB | |DB | |DB |
--- --- ---
\ |/
\| /
\ ---
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> 2EXPLAIN SELECT distinct s.gid, s.created, count(i.title) AS images
> FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active),
>relationship_wanted rw
> WHERE s.active AND s.status != 0
>AND EXISTS
On Wed, May 30, 2001 at 12:30:23PM -0400, Tom Lane wrote:
> Actually that's the least of the issues. The real problem is that
> because of function overloading, myfunc(int4) and myfunc(int2) (for
> example) are considered completely different functions. It is thus
> not at all clear what should
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Are these columns in pg_class:
> relukeys | relfkeys | relhaspkey
> unused or what?
They may be unused by the backend, but that doesn't mean that
applications don't look at them. I find references to relhaspkey
in pgaccess, for example.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I removed the reference in pgaccess. After a few releases of pgaccess
> we can remove the column.
Put it back please. Or have you become the unilateral arbiter of what
functions pgaccess has?
regards, tom lane
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have marked these columns as unused in pg_class.h.
Keep your hands off 'em!
There are other purposes for system catalogs besides the internal
convenience of the backend, you know. "Unused at the moment by the
backend" does not mean "removable" --- y
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Pgaccess is referencing system columns that are never set.
I wasn't aware that our standard procedure upon finding a bug was to rip
out the feature, rather than fixing the bug ... this could make life a
*lot* simpler.
If relhaspkey isn't set by table c
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Peter, can you give a little sample of how an elog() call would look in
>> the new system? Thanks.
> No change.
Wouldn't there need to be changes in the %-escape usage in elog message
strings?
regards, tom lane
--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Wouldn't there need to be changes in the %-escape usage in elog message
>> strings?
> Are you referring to the possibility that the parameters need to appear in
> a different order in the translated message? This can be handled if the
> translator
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the major problem was that our pg_proc table doesn't have any
> way of handling arg changes. In fact, we need a ALTER FUNCTION
> capability first so we can recreate functions in place with the same
> OID.
Actually that's the least of the issues
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I have a meta-point: the choices to be made here are not all that
> interesting. They do have to be defined. But almost any definition
> is OK.
Well, that implicit assumption is exactly the one I was questioning;
*is* it OK not to be very concerned
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> We have implemented multi-key index support for GiST. Patch is available
> from
>http://www.sai.msu.su/~megera/postgres/gist/code/7.1.2/patch_multikeygist.7.1.2.gz
What is the point of the macro
#define ATTGET(itup, Rel, i, isnull ) ((char*)( \
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> It is desirable to have some reasonable mechanism for changing the
> schema without requiring data to be dumped and reloaded. Otherwise it
> is very difficult to upgrade a system which needs to be up 24/7, such
> as many web sites today.
> It is not
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Also, what about foreign keys? At the moment it is incredibly complicated
> to determine all the foreign keys on a table, what column(s) they're defined
> over, what column(s) they reference and what their behaviour is. And just
> try writi
17 matches
Mail list logo
