Tom Lane wrote:
> One idea I thought about was to sort by index scan cost, using
> selectivity only as a tiebreaker for cost, rather than the other way
> around as is currently done. This seems fairly plausible because
> indexscans that are cheaper than other indexscans likely return fewer
> rows
Steve <[EMAIL PROTECTED]> writes:
> [ strange planner misbehavior in 8.2.3 ]
After some off-list investigation (thanks, Steve, for letting me poke
at your machine), the short answer is that the heuristics used by
choose_bitmap_and() suck. The problem query is like
select ... from ds where
ds.re
On Tue, 2007-04-10 at 12:18 -0700, Gurjeet Singh wrote:
> Also, although the whole plan-tree is available in
> get_relation_info(), but it wouldn't be the right place to scan other
> tables, for eg., for generating JOIN-INDEXes or materializing some
> intermediate joins. (sometime in the futur
Andrew Dunstan wrote:
>>> In cvs the file is marked as dead and gives a reference to cygwin's
>>> w32api.
>>> Maybe the answer is to simply note that the mingw-runtime binary from
>>> sourceforge above 3.9 has a broken sys/time.h (it is not the file from
>>> cygwin but the dead one from cvs).
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Writing lots of additional code simply to remove a parameter that
> *might* be mis-interpreted doesn't sound useful to me, especially when
> bugs may leak in that way. My take is that this is simple and useful
> *and* we have it now; other ways don't yet
On Fri, 2007-04-13 at 11:47 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
> >> That's what bothers me about this patch, too. It will be increasing
> >> the cost of writing WAL (more data -> more CRC computation and more
>
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
>> That's what bothers me about this patch, too. It will be increasing
>> the cost of writing WAL (more data -> more CRC computation and more
>> I/O, not to mention more contention for the WAL locks) whi
On Fri, 2007-04-13 at 10:36 -0400, Tom Lane wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> > But you also turn off the optimization that avoids writing regular
> > WAL records when the info is already contained in a full-page image
> > (increasing the uncompressed size of WAL).
Hi.
From: "Magnus Hagander" <[EMAIL PROTECTED]>
I see.
But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows
2000 and the windows IPV6 support.
Can you verify that it works if you manually add this #define and build
with MSVC6?
I don't have IPV6 test environment recently..
On Thu, 2007-04-12 at 15:56 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > transaction_guarantee.v11.patch
Thanks for the review.
> I can't help feeling that this is enormously overcomplicated.
I agree with all but one of your comments, see below.
> The "DFC" in partic
On Tue, 2007-04-10 at 11:40 +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >> I've been working on the patch to enhance our group commit behavior. The
> >> patch is a dirty hack at the moment, but I'm settled on the algorithm
> >> I'm going
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> But you also turn off the optimization that avoids writing regular
> WAL records when the info is already contained in a full-page image
> (increasing the uncompressed size of WAL).
> It was that part I questioned.
That's what bothers me a
Magnus Hagander wrote:
On Wed, Apr 11, 2007 at 06:17:19PM +0200, Zeugswetter Andreas ADI SD wrote:
That page is ages out of date. The intended sync is
apparently broken.
The current download area is on sourceforge
http://sf.net/project/showfiles.php?group_id=2435
I agree with Tom's reasoning about the suggested simplifications, sorry.
> > 3. Should the WALWriter also do the wal_buffers half-full write at
the
> > start of XLogInsert() ?
>
> That should go away entirely; to me the main point of the
> separate wal-writer process is to take over responsibi
On 4/13/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Dany DeBontridder wrote:
> I'm working to implement a new feature to pg_dump: the ability to dump
> objects like function, indexes...
pg_dump already dumps functions and indexes.
Right but you can't dump only one or two functions or
Am Freitag, 13. April 2007 14:28 schrieb Dany DeBontridder:
> But, in that case, those functions are only usable for pg_dump, what about
> the rest of code ? We don't have a central location for those small
> reusable snippets of code ?
The main point of these functions is to catch errors and exit
Hi,
char *
pg_strcat (char *dest,char *src)
{
/* pg_realloc is a safer function than realloc */
dest=pg_realloc(dest,strlen(dest)+strlen(src)+1);
strcat(dest,src);
return dest;
}
Postgres already has something for the above functionality.
See makeStringInfo, appendStringInfo.
Regards,
Nik
Dany DeBontridder wrote:
I'm working to implement a new feature to pg_dump: the ability to dump
objects like function, indexes...
pg_dump already dumps functions and indexes.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
Hi,
I'm working to implement a new feature to pg_dump: the ability to dump
objects like function, indexes... And I notice that there some usefull
functions like pg_malloc, pg_calloc... So I've added pg_free to avoid the
sequence if-not-null-free-point-to-NULL, now I'd like to add a function
pg_st
> > Yup, this is a good summary.
> >
> > You say you need to remove the optimization that avoids the logging
of
> > a new tuple because the full page image exists.
> > I think we must already have the info in WAL which tuple inside the
> > full page image is new (the one for which we avoided th
On Thu, Apr 12, 2007 at 08:46:09PM +0900, Hiroshi Saito wrote:
> >>src/include/pg_config.h.win32
> >>/* Define to 1 if you have support for IPv6. */
> >>// #define HAVE_IPV6 1
> >>
> >>What do you think?
> >
> >It's defined ni the msvc build script, see
> >http://archives.postgresql.org/pgsql-commi
On Wed, Apr 11, 2007 at 06:17:19PM +0200, Zeugswetter Andreas ADI SD wrote:
>
> > > That page is ages out of date. The intended sync is
> > apparently broken.
> > > The current download area is on sourceforge
> > > http://sf.net/project/showfiles.php?group_id=2435
> > >
> > >
> >
> > *sigh*
>
> I have this exact problem a lot. There are actually cases
> where you can eliminate regular joins, not just left joins.
> For example:
>
> CREATE TABLE partner (
> id serial,
> namevarchar(40) not null,
> primary key (id)
> );
>
>
On Fri, Apr 13, 2007 at 12:44:41AM -0600, Warren Turkal wrote:
> On Thursday 12 April 2007 00:56, you wrote:
> > IIRC, cmake is a replacement for make, not for configure. Or did I miss
> > something?
>
> CMake also has configure functionality.
>
> > And it would require rewriting all the unix mak
24 matches
Mail list logo
