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 th
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
> http://msdn2.microsoft.com/en-us/li
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 ha
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
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 b
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 f
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 be
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
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
pg_auth_members.grantor
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
