Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote:
As for GENERATED ALWAYS AS (expr), now that we understand that it's not
supposed to define a virtual column, what's the point?
We do need virtual columns, whether the spec requires them
Alvaro Herrera wrote:
Just got the report below in pgsql-es-ayuda. He says his logs files are
filled with 50 MB of the error message
LOG: SSL SYSCALL error: Unknown winsock error 10004
I looked up 10004 and apparently it's WSAEINTR, according to
I'm looking into PG/PLSql code and following code in
plpgsql_call_handler looks strange:
/* Find or compile the function */
func = plpgsql_compile(fcinfo, false);
/* Mark the function as busy, so it can't be deleted from under
us */
func-use_count++;
I don't
Sorry, 16x8K page ring is too small indeed. The reason we
selected 16 is because greenplum db runs on 32K page size, so
we are indeed reading 128K at a time. The #pages in the ring
should be made relative to the page size, so you achieve 128K
per read.
Ah, ok. New disks here also have a
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is not a race condition because the backend is single-threaded.
I see. Each backend has own function cache and use_count is for handle
recursion usage. Are my assumption correct?
Right. Once a function cache entry is set up, it
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm looking into PG/PLSql code and following code in
plpgsql_call_handler looks strange:
/* Find or compile the function */
func = plpgsql_compile(fcinfo, false);
/* Mark the function as busy, so it can't be
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm looking into PG/PLSql code and following code in
plpgsql_call_handler looks strange:
/* Find or compile the function */
func = plpgsql_compile(fcinfo, false);
/* Mark the function as busy, so it can't be deleted from
On Tue, 2007-05-08 at 08:08 -0400, Marshall, Steve wrote:
I think the optimization could work if you could exclude prepared
statements. However, I looked at the planning code and found no clear
way to distinguish between a statement being prepared for later
execution, and a statement being
Awhile back I wrote:
I did some tests just now to determine the total number of catalog
entries associated with a simple table definition. Assuming it has
N user columns of built-in types (hence not requiring pg_depend entries
for the datatypes), I count
1 pg_class entry for the table
I wrote:
I'll review my test methodology and keep testing...
I ran a set of tests on a 100 warehouse TPC-C stock table that is ~3.2
GB in size and the server has 4 GB of memory. IOW the table fits in OS
cache, but not in shared_buffers (set at 1 GB).
copy - COPY from a file
select - SELECT
So the discussion died again with nothing being decided. I see we have
several choices:
1. implement the standard, per Russell suggestion below
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
On 5/11/07, Tom Lane [EMAIL PROTECTED] wrote:
BTW, in the array patch as just committed, I was able to get rid of the
I am testing this feature, no problem so far. It's fast, and works
exactly as advertised! Great work! (aiui, no domain arrays for 8.3?)
merlin
12 matches
Mail list logo
