Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Here are some timing tests in 1m rows of random utf8 encoded 100 char
data. It doesn't look to me like the saving you're suggesting is worth
the trouble.
Hmm ... not sure I believe your numbers. Using a test file of 1m line
On Mar 17, 2007, at 10:33 PM, Luke Lonergan wrote:
Wow, nice!
Can you tell us:
- how big is the table
- cardinality of the column
- how big is the index in each case
- how much memory on the machine
- query and explain analyze
All I changed, was the 400k to 150k
512MB of ram, as I said earl
Wow, nice!
Can you tell us:
- how big is the table
- cardinality of the column
- how big is the index in each case
- how much memory on the machine
- query and explain analyze
Thanks!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Grzegorz Jaskiewicz [mailto:[EMAIL PRO
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Here are some timing tests in 1m rows of random utf8 encoded 100 char
data. It doesn't look to me like the saving you're suggesting is worth
the trouble.
Hmm ... not sure I believe your numbers. Using a test file of 1m line
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Here are some timing tests in 1m rows of random utf8 encoded 100 char
> data. It doesn't look to me like the saving you're suggesting is worth
> the trouble.
Hmm ... not sure I believe your numbers. Using a test file of 1m lines
of 100 random latin1
This is on dual ultra 2 sparc. with ultrawide 320 scsi drives. 512MB
ram.
I had to drop size of DB, because the DB drive is 4GB (I do welecome
bigger drives as donation, if someone asks - UWscsi 320).
here are my results. With only 4.2 patch (no maintain cluster order
v5 patch). If the v5 p
On Sun, 2007-03-18 at 00:44 +0530, Pavan Deolasee wrote:
> Simon Riggs wrote:
> >
> > We need to be clear that we already have a solution to CREATE INDEX
> > CONCURRENTLY. Do you agree that we do? Does anyone see a problem with
> > the posted design for that?
If we have solved CREATE INDEX CON
Mickael DELOISON wrote:
For a programming language, as it would be for GSoC, it has to be
realized in three month and I believe the utility has to be
cross-platform (anyway I want it to be). So I think Java would be
good. I am very used to Java and Swing programming. What do you think
about that
Tom Lane wrote:
I wrote:
Actually, I have to take back that objection: on closer look, COPY
validates the data only once and does so before applying its own
backslash-escaping rules. So there is a risk in that path too.
It's still pretty annoying to be validating the data twice
Hi.
I was operating in a tentative way by 2.3.
Still, it is not sufficient. However, it moves.
I will think that I am glad, if it can adjust with Magnus.
http://winpg.jp/~saito/MinGW/bison-2.3_win32_src.tgz
Regards,
Hiroshi Saito
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]
Simon Riggs wrote:
>
> We need to be clear that we already have a solution to CREATE INDEX
> CONCURRENTLY. Do you agree that we do? Does anyone see a problem with
> the posted design for that?
>
> Hopefully it is only CREATE INDEX that we need to think about.
>
I agree. Lets first decide whether
On Sat, 2007-03-17 at 23:11 +0530, Pavan Deolasee wrote:
> The algorithm would look like:
>
> 1. Disable HOT-updates
The lock held by CREATE INDEX already prevents HOT updates. So steps 1
and 8 aren't needed.
We need to be clear that we already have a solution to CREATE INDEX
CONCURRENTLY. Do y
Hello everybody.
I am a student and I would like to have your opinion on a project I
plan to submit for GSoC. At school, when I work with relational
databases I have problems to test tables' structure and queries
because I need to insert test data manually, which is very unpleasant.
Therefore, I
I wrote:
> Actually, I have to take back that objection: on closer look, COPY
> validates the data only once and does so before applying its own
> backslash-escaping rules. So there is a risk in that path too.
> It's still pretty annoying to be validating the data twice in the
> common case where
Simon Riggs wrote:
>
> As a result of the issues, I think Pavan is playing safe, to make sure
> there is *an* option, so that we can build upwards from there. The
> proposal is pragmatism only, while we discuss other approaches.
>
Absolutely true. I agree that CHILLing the table with AccessExclus
Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> While creating an index, if a HEAP_ONLY tuple is found,
>> CREATE INDEX [CONCURRENTLY] fails with an error and the
>> user needs to SET HOT OFF and then try again. While turning
>> HOT off, the entire table is CHILLed, holding Acces
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The problem with that is that it duplicates effort: in many cases
>> (especially COPY IN) the data's already been validated.
> One thought I had was that it might make sense to have a flag that would
> inhibit the check, that could b
On Sat, 2007-03-17 at 11:45 -0400, Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > While creating an index, if a HEAP_ONLY tuple is found,
> > CREATE INDEX [CONCURRENTLY] fails with an error and the
> > user needs to SET HOT OFF and then try again. While turning
> > HOT off, the
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Do you happen to have a 2.2 around so you can see what happens there? Or
> does someone else have that? So I know which version to test against...
2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to
test both last fall, and they genera
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Actually, looking at the GNU ftp site, there isn't even a version 2.2
>> available. There is a 2.1a which should have the fix (based on file
>> dates - they don't use branches or tags in their cvs repository).
>
> Huh? At
> http://f
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Actually, looking at the GNU ftp site, there isn't even a version 2.2
> available. There is a 2.1a which should have the fix (based on file
> dates - they don't use branches or tags in their cvs repository).
Huh? At
http://ftp.gnu.org/gnu/bison/
I see
Magnus Hagander wrote:
> I just tried building with Bison 2.1 on msvc, and it broke. For one
> thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
> obviously incorrect :-)
Actually, looking at the GNU ftp site, there isn't even a version 2.2
available. There is a 2.1a which should
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Last year Jeff suggested adding something like:
pg_verifymbstr(string,strlen(string),0);
to each relevant input routine. Would that be an acceptable solution?
The problem with that is that it duplicates effort: in many ca
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The attached patch seems to fix the build issue. Does it seem
>> acceptable/the right thing to do?
>
> No, it seems pretty bletcherous.
That's kind of what I thought :-)
>> Another option would be to just reject both 2.0 and 2.1 a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Last year Jeff suggested adding something like:
> pg_verifymbstr(string,strlen(string),0);
> to each relevant input routine. Would that be an acceptable solution?
The problem with that is that it duplicates effort: in many cases
(especially COPY IN)
Nikolay Samokhvalov wrote:
On 3/17/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
In principle I am in favor of the patch.
Would it be better to use some more unlikely name for the dummy root
element used to process fragments than ?
Perhaps even something in a special namespace?
I did thi
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The attached patch seems to fix the build issue. Does it seem
> acceptable/the right thing to do?
No, it seems pretty bletcherous.
> Another option would be to just reject both 2.0 and 2.1 as broken to
> build pg with, I guess...
In bison 2.3 (which
Jeff Davis wrote:
On Wed, 2007-03-14 at 01:29 -0600, Michael Fuhr wrote:
On Tue, Mar 13, 2007 at 04:42:35PM +0100, Mario Weilguni wrote:
Am Dienstag, 13. März 2007 16:38 schrieb Joshua D. Drake:
Is this any different than the issues of moving 8.0.x to 8.1 UTF8? Where
we had to
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> While creating an index, if a HEAP_ONLY tuple is found,
> CREATE INDEX [CONCURRENTLY] fails with an error and the
> user needs to SET HOT OFF and then try again. While turning
> HOT off, the entire table is CHILLed, holding AccessExclusive
> lock on th
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On 3/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> In the second place, it's a serious violation of what little modularity
>> and layering we have for fd.c to be calling into commands/tablespace.c.
>> This is not merely cosmetic but has real consequence
> > ECPG Enhancments: Enable ECPG to generate calls directly for libpq
> > rather than calls to its own libraries.
> >
> > What would be the point of that?
>
> More importantly, Michael hasn't volunteered to mentor this year, so I think
> we should probably take the idea down.
And most important
On 3/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
In the second place, it's a serious violation of what little modularity
and layering we have for fd.c to be calling into commands/tablespace.c.
This is not merely cosmetic but has real consequences: one being that
it's now unsafe to call OpenTemporar
Nikolay Samokhvalov wrote:
What about it? W/o this not large patch XML functionality in 8.3 will
be weak...
Will it be accepted?
In principle I am in favor of the patch.
Would it be better to use some more unlikely name for the dummy root
element used to process fragments than ?
Perhap
What about it? W/o this not large patch XML functionality in 8.3 will be weak...
Will it be accepted?
On 3/5/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> I'll fix these issues and extend the patch with resgression tests and
> docs
Grzegorz Jaskiewicz wrote:
>
> On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
>
>
>>
>> You'll obviously need to run it with the patch applied. I'd suggest to
>> enable stats_block_level to see the effect on buffer cache hit/miss
>> ratio.
>
> groupeditems-42-pghead.patch.gz is enough,
Magnus Hagander wrote:
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az
I just tried building with Bison 2.1 on msvc, and it broke. For one
thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is
obviously incorrect :-)
But the generated C file also does not compile causing the error on
http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc
d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Mar 16, 2007 at 09:56:23AM -0400, Andrew Dunstan wrote:
> [EMAIL PROTECTED] wrote:
> >
> >>Does hstore nest? [...]
> >
> >If what you mean is to have "mappings of mappings" then no.
> > [...] think "hash" for perl folks [...]
> As a perl folk
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the effect on buffer cache hit/
miss ratio.
groupeditems-42-pghead.patch.gz is enough, or it needs
maintain_cluster_order_v5.pa
On Sat, 2007-03-17 at 12:43 +0530, Pavan Deolasee wrote:
> How do we move forward with the CREATE INDEX issue with
> HOT ? There are quite a few suggestions and objections.
> Can we please discuss and decide on the plan ? I am very
> comfortable with the current state of HOT, the results
> are enco
40 matches
Mail list logo
