"Tom Lane" <[EMAIL PROTECTED]> writes
>
> Please exhibit a case in which you feel this is needed.
>
Suppose I want to print a debug info in parseTypeString() like this:
+ elog(DEBUG1, "parse type %s", buf.data);
raw_parsetree_list = raw_parser(buf.data);
Rebuild the server, psql it:
Tom,
> As best I can tell, my version of CopyReadAttributes is significantly
> quicker than Alon's, approximately balancing out the fact that my
> version of CopyReadLine is slower. I did the latter first, and would
> now be tempted to rewrite it in the same style as CopyReadAttributes,
> ie one
Andrew,
> Arguably this might exaggerate the effect quite significantly. Users
> will want to know the real time effect on a complete COPY. Depending on
> how much the pasing is in the total time your 20% improvement in parsing
> might only be a small fraction of 20% improvement in COPY.
Arguabl
On Tue, Aug 09, 2005 at 11:24:40PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hmm. I have a patch for this, but now that it's ready, I wonder if it's
> > really needed. If I understand vacuum_set_xid_limits() correctly, it's
> > very difficult for the vacuumxid to be
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm. I have a patch for this, but now that it's ready, I wonder if it's
> really needed. If I understand vacuum_set_xid_limits() correctly, it's
> very difficult for the vacuumxid to be far behind the freeze limit.
Umm ... they can be close together,
On Fri, Jul 29, 2005 at 03:33:09PM -0400, Tom Lane wrote:
> It occurs to me that vacuuming to prevent XID wraparound is not the only
> reason to do DB-wide vacuums: we also need to keep
> pg_database.datvacuumxid from getting too old, else we will have
> problems with clog bloat. We may need to r
Alon Goldshuv wrote:
I performed those measurement by executing *only the parsing logic* of the
COPY pipeline. All data conversion (functioncall3(string...)) and tuple
handling (form_heaptuple etc...) and insertion were manually disabled. So
the only code measured is reading from disk and pars
I did some performance checks after the recent code commit.
The good news is that the parsing speed of COPY is now MUCH faster, which is
great. It is about 5 times faster - about 100MB/sec on my machine
(previously 20MB/sec at best, usually less).
The better news is that my original patch parsing
Simon Riggs <[EMAIL PROTECTED]> writes:
> There once was a rumour of a EXPLAIN EXECUTE command.
> This minor patch removes all trace of that, but without disturbing other
> valid occurrences of the EXECUTE command, which still lives on.
It's not as dead as you seem to think.
regression=# prepare
There once was a rumour of a EXPLAIN EXECUTE command.
This minor patch removes all trace of that, but without disturbing other
valid occurrences of the EXECUTE command, which still lives on.
Best Regards, Simon Riggs
Index: commands/explain.c
==
Mark Wong wrote:
> O_DIRECT + fsync() can make sense. It avoids the copying of data
> to the page cache before being written and will also guarantee
> that the file's metadata is also written to disk. It also
> prevents the page cache from filling up with write data that
> will never be read (I a
On Mon, 2005-08-08 at 17:18 -0400, Tom Lane wrote:
> If you think that this should be a global option instead of a
> per-statement one, something like the (undocumented) #option hack might
> be a good way to specify it; that would give it per-function scope,
> which seems reasonable.
>
> cre
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Since we will invoke callback functions unconditionally in errfinish(), so
> pts_error_callback() should not report "invalid type name" without checking
> current error status.
Please exhibit a case in which you feel this is needed.
13 matches
Mail list logo
